Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 29 August 2014 08:19, Thierry Reding  wrote:
> On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
>> On 28 August 2014 12:08, Thierry Reding  wrote:
>> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> >> Hello,
>> >>
>> >> On 27 August 2014 17:42, Maxime Ripard  
>> >> wrote:
>> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> >> >> [...]
>> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT 
>> >> >> > > > > > property:
>> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
>> >> >> > > > >
>> >> >> > > > > Mike says in that email that he's opposing the addition of a 
>> >> >> > > > > property
>> >> >> > > > > for clocks that is the equivalent of regulator-always-on. 
>> >> >> > > > > That's not
>> >> >> > > > > what this is about. If at all it'd be a property to mark a 
>> >> >> > > > > clock that
>> >> >> > > > > should not be disabled by default because it's essential.
>> >> >> > > >
>> >> >> > > > It's just semantic. How is "a clock that should not be disabled 
>> >> >> > > > by
>> >> >> > > > default because it's essential" not a clock that stays always on?
>> >> >> > >
>> >> >> > > Because a clock that should not be disabled by default can be 
>> >> >> > > turned off
>> >> >> > > when appropriate. A clock that is always on can't be turned off.
>> >> >> >
>> >> >> > If a clock is essential, then it should never be disabled. Or we 
>> >> >> > don't
>> >> >> > share the same meaning of essential.
>> >> >>
>> >> >> Essential for the particular use-case.
>> >> >
>> >> > So, how would the clock driver would know about which use case we're
>> >> > in? How would it know about which display engine is currently running?
>> >> > How would it know about which video output is being set?
>> >> >
>> >> > Currently, we have two separate display engines, which can each output
>> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> >> > one of these combinations would require different clocks. What clocks
>> >> > will we put in the driver? All of them?
>> >> >
>> >>
>> >> since simplefb cannot be extended how about adding, say, dtfb which
>> >> claims the resources from dt and then instantiates a simplefb once the
>> >> resources are claimed? That is have a dtfb which has the clocks
>> >> assigned and has simplefb as child dt node.
>> >
>> > I don't see how that changes anything. All you do is add another layer
>> > of indirection. The fundamental problem remains the same and isn't
>> > solved.
>>
>> It keeps clock code out of simplefb and provides driver for the kind
>> of framebuffer set up by firmware that exists on sunxi, exynos, and
>> probably many other SoCs. That is a framebuffer that needs some clocks
>> and possibly regulators enabled to keep running because the reality of
>> the platform is that it has clocks and regulators unlike some other
>> platforms that do not.
>>
>> These clocks and regulators are used but not configured by the
>> framebuffer and should be reclaimed when firmware framebuffer is
>> disabled. This is the same as the chunk of  memory used by simplefb
>> which is currently lost but should be reclaimed when simplefb is
>> disabled.
>>
>> This memory is not 'reserved for firmware' and unusable but reserved
>> for framebuffer and the regulators are not 'always on' or 'should
>> never be disabled' but should be enabled while framebuffer is used.
>>
>> As far as I can tell in DT this is expressed by creating a DT node
>> associated with the framebuffer driver that tells the kernel that this
>> memory, clocks and regulators are associated with the framebuffer
>> driver and can be reclaimed if this driver is stopped or not enabled
>> in the kernel at all. If you are going to be asinine about simplefb
>> not getting support for managing any resource other than the memory
>> chunk then another layer of indirection is required for platforms that
>> have more resources to manage.
>>
>> If there is another way to associate resources with a driver in DT
>> then please enlighten me.
>>
>> AFAICT simplefb is the framebuffer driver already in kernel closest to
>> the driver that is required for sunxi - simplefb also relies on
>> firmware to set up the framebuffer but unlike vesafb or efifb it
>> already has DT integration. So the most efficient way to implement
>> framebuffer for sunxi is to extend simplefb or if necessary add
>> another layer of indirection under simplefb. If there is a better
>> fitting driver in the kernel then please enlighten me and the
>> developer that wrote this patch what driver it would be.
>
> I think simplefb is exactly the right driver to use for this case. But I
> d

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Thu, Aug 28, 2014 at 10:46:03PM +0200, Maxime Ripard wrote:
> On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
[...]
> > Then since firmware already knows what it set up it can tell the
> > kernel to not touch those.
> 
> Somehow, I've been raised kernel-wise into thinking that you can never
> fully trust your firmware. Or at least that you should have a way to
> recover from any bug/bad behaviour from it.

If you don't trust your firmware then you shouldn't be taking over a
device that it's set up for you. Rather you should write a proper driver
that sets things up from the start.

This whole "we don't trust firmware" isn't going to work if we want to
have hand-off from firmware to kernel. And it's already been decided in
other threads that moving more code out of the kernel and into firmware
is a requirement (c.f. ARM64).

Also in this case you wrote the firmware, so why wouldn't you trust it?

> Moreover, the way I see it, there's a major flaw in having an
> attribute in the clock node: you don't even know if the clock is ever
> going to be used.
> 
> If simplefb is not compiled in, you won't claim the clocks, and they
> will be disabled, which is imho a good thing. This case wouldn't be
> covered with an attribute at the clock node, because you don't have a
> link to what device/feature actually uses it in the system, and so you
> have to make the assumption that it will be used. And you will end up
> with clocks with a rather high rate running for nothing.

That's completely hypothetical. If simplefb isn't enabled and the clock
isn't claimed there's probably still going to be some other driver
taking over eventually. If there isn't, what's the point of firmware
setting up display in the first case?

Thierry


pgphhjmwCZJXr.pgp
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Fri, Aug 29, 2014 at 07:13:22AM +0200, Michal Suchanek wrote:
> On 28 August 2014 12:08, Thierry Reding  wrote:
> > On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> >> Hello,
> >>
> >> On 27 August 2014 17:42, Maxime Ripard  
> >> wrote:
> >> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> >> [...]
> >> >> > > > > > Mike Turquette repeatedly said that he was against such a DT 
> >> >> > > > > > property:
> >> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> >> > > > >
> >> >> > > > > Mike says in that email that he's opposing the addition of a 
> >> >> > > > > property
> >> >> > > > > for clocks that is the equivalent of regulator-always-on. 
> >> >> > > > > That's not
> >> >> > > > > what this is about. If at all it'd be a property to mark a 
> >> >> > > > > clock that
> >> >> > > > > should not be disabled by default because it's essential.
> >> >> > > >
> >> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> >> > > > default because it's essential" not a clock that stays always on?
> >> >> > >
> >> >> > > Because a clock that should not be disabled by default can be 
> >> >> > > turned off
> >> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >> >
> >> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> >> > share the same meaning of essential.
> >> >>
> >> >> Essential for the particular use-case.
> >> >
> >> > So, how would the clock driver would know about which use case we're
> >> > in? How would it know about which display engine is currently running?
> >> > How would it know about which video output is being set?
> >> >
> >> > Currently, we have two separate display engines, which can each output
> >> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> >> > one of these combinations would require different clocks. What clocks
> >> > will we put in the driver? All of them?
> >> >
> >>
> >> since simplefb cannot be extended how about adding, say, dtfb which
> >> claims the resources from dt and then instantiates a simplefb once the
> >> resources are claimed? That is have a dtfb which has the clocks
> >> assigned and has simplefb as child dt node.
> >
> > I don't see how that changes anything. All you do is add another layer
> > of indirection. The fundamental problem remains the same and isn't
> > solved.
> 
> It keeps clock code out of simplefb and provides driver for the kind
> of framebuffer set up by firmware that exists on sunxi, exynos, and
> probably many other SoCs. That is a framebuffer that needs some clocks
> and possibly regulators enabled to keep running because the reality of
> the platform is that it has clocks and regulators unlike some other
> platforms that do not.
> 
> These clocks and regulators are used but not configured by the
> framebuffer and should be reclaimed when firmware framebuffer is
> disabled. This is the same as the chunk of  memory used by simplefb
> which is currently lost but should be reclaimed when simplefb is
> disabled.
> 
> This memory is not 'reserved for firmware' and unusable but reserved
> for framebuffer and the regulators are not 'always on' or 'should
> never be disabled' but should be enabled while framebuffer is used.
> 
> As far as I can tell in DT this is expressed by creating a DT node
> associated with the framebuffer driver that tells the kernel that this
> memory, clocks and regulators are associated with the framebuffer
> driver and can be reclaimed if this driver is stopped or not enabled
> in the kernel at all. If you are going to be asinine about simplefb
> not getting support for managing any resource other than the memory
> chunk then another layer of indirection is required for platforms that
> have more resources to manage.
> 
> If there is another way to associate resources with a driver in DT
> then please enlighten me.
> 
> AFAICT simplefb is the framebuffer driver already in kernel closest to
> the driver that is required for sunxi - simplefb also relies on
> firmware to set up the framebuffer but unlike vesafb or efifb it
> already has DT integration. So the most efficient way to implement
> framebuffer for sunxi is to extend simplefb or if necessary add
> another layer of indirection under simplefb. If there is a better
> fitting driver in the kernel then please enlighten me and the
> developer that wrote this patch what driver it would be.

I think simplefb is exactly the right driver to use for this case. But I
don't think making it manage all the resources is the right thing to do.
While it's fairly easy to do it, it's also something that needs to be
done for every other driver

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 12:08, Thierry Reding  wrote:
> On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
>> Hello,
>>
>> On 27 August 2014 17:42, Maxime Ripard  
>> wrote:
>> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> >> [...]
>> >> > > > > > Mike Turquette repeatedly said that he was against such a DT 
>> >> > > > > > property:
>> >> > > > > > https://lkml.org/lkml/2014/5/12/693
>> >> > > > >
>> >> > > > > Mike says in that email that he's opposing the addition of a 
>> >> > > > > property
>> >> > > > > for clocks that is the equivalent of regulator-always-on. That's 
>> >> > > > > not
>> >> > > > > what this is about. If at all it'd be a property to mark a clock 
>> >> > > > > that
>> >> > > > > should not be disabled by default because it's essential.
>> >> > > >
>> >> > > > It's just semantic. How is "a clock that should not be disabled by
>> >> > > > default because it's essential" not a clock that stays always on?
>> >> > >
>> >> > > Because a clock that should not be disabled by default can be turned 
>> >> > > off
>> >> > > when appropriate. A clock that is always on can't be turned off.
>> >> >
>> >> > If a clock is essential, then it should never be disabled. Or we don't
>> >> > share the same meaning of essential.
>> >>
>> >> Essential for the particular use-case.
>> >
>> > So, how would the clock driver would know about which use case we're
>> > in? How would it know about which display engine is currently running?
>> > How would it know about which video output is being set?
>> >
>> > Currently, we have two separate display engines, which can each output
>> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> > one of these combinations would require different clocks. What clocks
>> > will we put in the driver? All of them?
>> >
>>
>> since simplefb cannot be extended how about adding, say, dtfb which
>> claims the resources from dt and then instantiates a simplefb once the
>> resources are claimed? That is have a dtfb which has the clocks
>> assigned and has simplefb as child dt node.
>
> I don't see how that changes anything. All you do is add another layer
> of indirection. The fundamental problem remains the same and isn't
> solved.

It keeps clock code out of simplefb and provides driver for the kind
of framebuffer set up by firmware that exists on sunxi, exynos, and
probably many other SoCs. That is a framebuffer that needs some clocks
and possibly regulators enabled to keep running because the reality of
the platform is that it has clocks and regulators unlike some other
platforms that do not.

These clocks and regulators are used but not configured by the
framebuffer and should be reclaimed when firmware framebuffer is
disabled. This is the same as the chunk of  memory used by simplefb
which is currently lost but should be reclaimed when simplefb is
disabled.

This memory is not 'reserved for firmware' and unusable but reserved
for framebuffer and the regulators are not 'always on' or 'should
never be disabled' but should be enabled while framebuffer is used.

As far as I can tell in DT this is expressed by creating a DT node
associated with the framebuffer driver that tells the kernel that this
memory, clocks and regulators are associated with the framebuffer
driver and can be reclaimed if this driver is stopped or not enabled
in the kernel at all. If you are going to be asinine about simplefb
not getting support for managing any resource other than the memory
chunk then another layer of indirection is required for platforms that
have more resources to manage.

If there is another way to associate resources with a driver in DT
then please enlighten me.

AFAICT simplefb is the framebuffer driver already in kernel closest to
the driver that is required for sunxi - simplefb also relies on
firmware to set up the framebuffer but unlike vesafb or efifb it
already has DT integration. So the most efficient way to implement
framebuffer for sunxi is to extend simplefb or if necessary add
another layer of indirection under simplefb. If there is a better
fitting driver in the kernel then please enlighten me and the
developer that wrote this patch what driver it would be.

Thanks

Michal

-- 
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: GPL Violations round-up

[Quink]

Speaking something wrong is worse than do nothing. If you are
too serious about this problem, Aw will keep their mouth tight.
Relax and try to communicate with them. Maybe Aw has made
some improvements that we didn't know. Just blame his students
 is not a good teacher.


On Thu, Aug 28, 2014 at 9:35 PM, Stefan Monnier 
wrote:

> > So please stop attacking AW in this way.
>
> FWIW, I agree with Luc that it's important to bring this up and make
> sure that there's some positive movement on that front.
> Even if it's limited to splitting the blob into a "Free" glue code
> linked to a binary blob.
>
> And it doesn't have to get all fixed right away before we can do
> anything else.  But there's a need to establish some understanding
> between the two parties about this issue.
>
>
> Stefan
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [linux-sunxi] Who is reviewing the sunxi-boards repo?

[Luc Verhaegen]

On Fri, Aug 29, 2014 at 12:04:24AM +0200, Dorian Meid wrote:
> Hello,
> 
> I was wondering why there are so many unresponded pull requests for 
> sunxi-boars goning back till january without any discussion.
> I don't wnat to complain, all of you are doing a great effort, I just 
> wonder.

Which specific pull request are you that interested in, and is there a 
complete device page for it? http://linux-sunxi.org/New_Device_howto

Luc Verhaegen.

-- 
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] Cannot power off A13 tablet when connected to PC

[Michal Suchanek]

Hello,

I noticed problem with AXP in A13 tablets. When the tablet is
connected to PC and powered from OTG port it cannot be powered off -
it reboots instead.

Note that Android displays battery charging animation in this case so
the behaviour might be expected and should just be handled by acpi
scripts.

Any idea if and how this can be fixed?

Thanks

Michal

-- 
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] Who is reviewing the sunxi-boards repo?

[Dorian Meid]

Hello,

I was wondering why there are so many unresponded pull requests for sunxi-boars 
goning back till january without any discussion.
I don't wnat to complain, all of you are doing a great effort, I just wonder.

Dorian Meid



-- 
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: [PATCH 4/4] simplefb: add clock handling code

[Maxime Ripard]

On Thu, Aug 28, 2014 at 12:11:41PM +0200, Thierry Reding wrote:
> On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> > > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > > [...]
> > > > > > > > Mike Turquette repeatedly said that he was against such a DT 
> > > > > > > > property:
> > > > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > > > 
> > > > > > > Mike says in that email that he's opposing the addition of a 
> > > > > > > property
> > > > > > > for clocks that is the equivalent of regulator-always-on. That's 
> > > > > > > not
> > > > > > > what this is about. If at all it'd be a property to mark a clock 
> > > > > > > that
> > > > > > > should not be disabled by default because it's essential.
> > > > > > 
> > > > > > It's just semantic. How is "a clock that should not be disabled by
> > > > > > default because it's essential" not a clock that stays always on?
> > > > > 
> > > > > Because a clock that should not be disabled by default can be turned 
> > > > > off
> > > > > when appropriate. A clock that is always on can't be turned off.
> > > > 
> > > > If a clock is essential, then it should never be disabled. Or we don't
> > > > share the same meaning of essential.
> > > 
> > > Essential for the particular use-case.
> > 
> > So, how would the clock driver would know about which use case we're
> > in? How would it know about which display engine is currently running?
> > How would it know about which video output is being set?
> > 
> > Currently, we have two separate display engines, which can each output
> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> > one of these combinations would require different clocks. What clocks
> > will we put in the driver? All of them?
> 
> Ideally the solution wouldn't involve hard-coding this into the clock
> driver at all.

Cool, so we do agree on that too :)

> There should be a way for firmware to communicate to the kernel that
> a given clock shouldn't be disabled.

And this patch was such an attempt. I guess it wasn't that far off
then.

> Then since firmware already knows what it set up it can tell the
> kernel to not touch those.

Somehow, I've been raised kernel-wise into thinking that you can never
fully trust your firmware. Or at least that you should have a way to
recover from any bug/bad behaviour from it.

Moreover, the way I see it, there's a major flaw in having an
attribute in the clock node: you don't even know if the clock is ever
going to be used.

If simplefb is not compiled in, you won't claim the clocks, and they
will be disabled, which is imho a good thing. This case wouldn't be
covered with an attribute at the clock node, because you don't have a
link to what device/feature actually uses it in the system, and so you
have to make the assumption that it will be used. And you will end up
with clocks with a rather high rate running for nothing.

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


signature.asc
Description: Digital signature

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 18:34, jonsm...@gmail.com  wrote:
> On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek  wrote:
>> On 28 August 2014 16:33, jonsm...@gmail.com  wrote:
>>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>>>  wrote:
 On Thu, Aug 28, 2014 at 3:22 PM, jonsm...@gmail.com  
 wrote:
>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>> driver, instead the bootloader should tell the kernel about these clocks.
>>
>> So the only point of discussion left seems to be how to do 2...
>
> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
> whip together a device specific driver that claims the proper
> resources? And just implement the minimal about of fbdev possible?
> fbdev already is a driver library.

 Like... drivers/video/fbdev/offb.c?
>>>
>>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>>> and use it as a template for making device specific versions of it.
>>>
>>> I don't see why there is so much resistance to just making device
>>> specific fb drivers.  Whenever the KMS driver gets written just
>>> disable the device specific fb driver in the build.
>>
>> Except that is not the goal here. The simplefb or whatever replacement
>> is supposed to stay as a  generic driver compiled into kernel whereas
>
> There is no generic solution to this problem as this entire thread has
> illustrated. The clocks/regulators needed by each SOC vary.
>
> So there are two solutions..
> 1) modify simplefb to have some kind of heuristic that tries to guess
> what needs to be protected. A heuristic that is probably going to fail
> on every new SOC.

You do not need a heuristic when the bootloader that enabled the
clocks and regulators can tell you which.

And this patch was initially about adding support to simplefb to read
from DT where u-boot fills in the clocks that are needed for HDMI
output to keep running on sunxi.

>
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.

But then you need to spend a day implementing such driver for every
SoC and it will not work before initrd is loaded.

In contrast simplefb with resource management support can work on any
platform where the bootloader enables framebuffer and then can be
compiled into generic kernel and work before even initrd is loaded.

Thanks

Michal

-- 
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] GPL Violations round-up.

[Maxime Ripard]

On Thu, Aug 28, 2014 at 02:51:56PM +0200, Luc Verhaegen wrote:
> On Thu, Aug 28, 2014 at 02:29:46PM +0200, Michal Suchanek wrote:
> > On 28 August 2014 13:57, Luc Verhaegen  wrote:
> > > On Thu, Aug 28, 2014 at 10:07:46AM +0300, Simos Xenitellis wrote:
> > >> It is indeed bad blood. Let's see a few:
> > >>
> > >> 1. "*Allwinner  does not actively
> > >> participate in or support this community. In fact, it is violating the
> > >> GPLv2 license  in several ways and
> > >> has so far not shown willingness to resolve this."*
> > >> Source: http://linux-sunxi.org/Main_Page (it is in bold, on the first 
> > >> page
> > >> of the Wiki!)
> > >
> > > Allwinner never has participated or supported this community so far. It
> > 
> > This is simply not true.
> > 
> > Allwinner has provided devboards and probably some docs and sources
> > upon request.
> 
> Facts please.
> 
> I know Oliver got sent a 50usd A33 tablet just now, even though he got 
> told he would get an a23 tablet shortly before allwinner joined linaro. 
> 
> What else?

I got an A31 EVK a bit more than a year ago. 

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


signature.asc
Description: Digital signature

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Luc Verhaegen]

On Thu, Aug 28, 2014 at 12:34:58PM -0400, jonsm...@gmail.com wrote:
> 
> 2) Spend a day implementing a device specific fbdev driver that does
> the correct thing all of the time. These drivers would sit in initrd
> and load before the clock/regulator clean up shuts everything off. Use
> the existing simplefb code as a template for doing this.

If that finally ends this discussion, i'll more than happily do it. I'm 
sure that we've all could've done this a hundred times in the time we've
wasted here.

Good call Geert.

Luc Verhaegen.

-- 
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: [PATCH 4/4] simplefb: add clock handling code

[jonsm...@gmail.com]

On Thu, Aug 28, 2014 at 12:25 PM, Michal Suchanek  wrote:
> On 28 August 2014 16:33, jonsm...@gmail.com  wrote:
>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>>  wrote:
>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsm...@gmail.com  
>>> wrote:
> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
> driver, instead the bootloader should tell the kernel about these clocks.
>
> So the only point of discussion left seems to be how to do 2...

 Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
 whip together a device specific driver that claims the proper
 resources? And just implement the minimal about of fbdev possible?
 fbdev already is a driver library.
>>>
>>> Like... drivers/video/fbdev/offb.c?
>>
>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>> and use it as a template for making device specific versions of it.
>>
>> I don't see why there is so much resistance to just making device
>> specific fb drivers.  Whenever the KMS driver gets written just
>> disable the device specific fb driver in the build.
>
> Except that is not the goal here. The simplefb or whatever replacement
> is supposed to stay as a  generic driver compiled into kernel whereas

There is no generic solution to this problem as this entire thread has
illustrated. The clocks/regulators needed by each SOC vary.

So there are two solutions..
1) modify simplefb to have some kind of heuristic that tries to guess
what needs to be protected. A heuristic that is probably going to fail
on every new SOC.

2) Spend a day implementing a device specific fbdev driver that does
the correct thing all of the time. These drivers would sit in initrd
and load before the clock/regulator clean up shuts everything off. Use
the existing simplefb code as a template for doing this.


> the complete platform-specific driver is supposed to be provided as
> module and loaded at the init system's leasure sometime during boot.
> This way you can have generic distribution kernel which supports many
> devices but does not have built-in support for every graphics
> hardware.
>
> Thanks
>
> Michal
>
> --
> 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.



-- 
Jon Smirl
jonsm...@gmail.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.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 16:33, jonsm...@gmail.com  wrote:
> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>  wrote:
>> On Thu, Aug 28, 2014 at 3:22 PM, jonsm...@gmail.com  
>> wrote:
 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
 driver, instead the bootloader should tell the kernel about these clocks.

 So the only point of discussion left seems to be how to do 2...
>>>
>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>> whip together a device specific driver that claims the proper
>>> resources? And just implement the minimal about of fbdev possible?
>>> fbdev already is a driver library.
>>
>> Like... drivers/video/fbdev/offb.c?
>
> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> and use it as a template for making device specific versions of it.
>
> I don't see why there is so much resistance to just making device
> specific fb drivers.  Whenever the KMS driver gets written just
> disable the device specific fb driver in the build.

Except that is not the goal here. The simplefb or whatever replacement
is supposed to stay as a  generic driver compiled into kernel whereas
the complete platform-specific driver is supposed to be provided as
module and loaded at the init system's leasure sometime during boot.
This way you can have generic distribution kernel which supports many
devices but does not have built-in support for every graphics
hardware.

Thanks

Michal

-- 
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] GPL Violations round-up.

[Michal Suchanek]

On 28 August 2014 16:25, Luc Verhaegen  wrote:
> On Thu, Aug 28, 2014 at 04:07:11PM +0200, Michal Suchanek wrote:
>> On 28 August 2014 14:51, Luc Verhaegen  wrote:
>> > On Thu, Aug 28, 2014 at 02:29:46PM +0200, Michal Suchanek wrote:
>> >
>> > Facts please.
>> >
>> > I know Oliver got sent a 50usd A33 tablet just now, even though he got
>> > told he would get an a23 tablet shortly before allwinner joined linaro.
>> >
>> > What else?
>> >
>> > Again, facts.
>> >
>> > We only get SDK sources (for some decreasing value thereof) from device
>> > makers. Which of the docs that we have came from allwinner directly, and
>> > didn't come from some other source?
>>
>> Where did the a20 libnand and spl source come from?
>
> I don't know, why don't you tell me?
>
> Plus, if we have the source code for libnand for a20, then why is
> it listed on: http://linux-sunxi.org/A20#GPL_Violations
>
> I believe that a A20 libnand blob was mentioned many times in this
> thread already. Why has this not been refuted by you or others?
>

It was mentioned among list of chips for which the libnand source is
not available.

I cannot say anything about a23, a31, a80 and whatnot but I noticed
somebody provided a link for quite complete a20 SDK from which this
code comes: 
https://github.com/hramrach/linux-sunxi/commit/043021b2d365894d5226ea5b6f7a0aa870dcd630
I do not think the actual code ever landed in the sunxi kernel but was
probably used as reference for improving the nand support on a20.

I do not remember anymore who provided the link but it is surely
logged somewhere in the IRC logs. I do not know who released this code
to the public, though.

Thanks

Michal

-- 
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: [PATCH 4/4] simplefb: add clock handling code

[jonsm...@gmail.com]

On Thu, Aug 28, 2014 at 10:37 AM, Geert Uytterhoeven
 wrote:
> On Thu, Aug 28, 2014 at 4:33 PM, jonsm...@gmail.com  
> wrote:
>> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>>  wrote:
>>> On Thu, Aug 28, 2014 at 3:22 PM, jonsm...@gmail.com  
>>> wrote:
> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
> driver, instead the bootloader should tell the kernel about these clocks.
>
> So the only point of discussion left seems to be how to do 2...

 Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
 whip together a device specific driver that claims the proper
 resources? And just implement the minimal about of fbdev possible?
 fbdev already is a driver library.
>>>
>>> Like... drivers/video/fbdev/offb.c?
>>
>> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
>> and use it as a template for making device specific versions of it.
>>
>> I don't see why there is so much resistance to just making device
>> specific fb drivers.  Whenever the KMS driver gets written just
>> disable the device specific fb driver in the build.
>
> I explicitly named offb, because it already supports living with the
> video mode initialized by Open Firmware, which is passed to the kernel
> in a device tree.

Not sure how that works. It from a PowerMac

arch/powerpc/platforms/powermac/bootx_init.c
arch/powerpc/kernel/prom_init.c

>
> --
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds



-- 
Jon Smirl
jonsm...@gmail.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.

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Aug 28, 2014 at 4:33 PM, jonsm...@gmail.com  wrote:
> On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
>  wrote:
>> On Thu, Aug 28, 2014 at 3:22 PM, jonsm...@gmail.com  
>> wrote:
 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
 driver, instead the bootloader should tell the kernel about these clocks.

 So the only point of discussion left seems to be how to do 2...
>>>
>>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>>> whip together a device specific driver that claims the proper
>>> resources? And just implement the minimal about of fbdev possible?
>>> fbdev already is a driver library.
>>
>> Like... drivers/video/fbdev/offb.c?
>
> I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
> and use it as a template for making device specific versions of it.
>
> I don't see why there is so much resistance to just making device
> specific fb drivers.  Whenever the KMS driver gets written just
> disable the device specific fb driver in the build.

I explicitly named offb, because it already supports living with the
video mode initialized by Open Firmware, which is passed to the kernel
in a device tree.

-- 
Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-- 
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: [PATCH 4/4] simplefb: add clock handling code

[jonsm...@gmail.com]

On Thu, Aug 28, 2014 at 10:20 AM, Geert Uytterhoeven
 wrote:
> On Thu, Aug 28, 2014 at 3:22 PM, jonsm...@gmail.com  
> wrote:
>>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>>> driver, instead the bootloader should tell the kernel about these clocks.
>>>
>>> So the only point of discussion left seems to be how to do 2...
>>
>> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
>> whip together a device specific driver that claims the proper
>> resources? And just implement the minimal about of fbdev possible?
>> fbdev already is a driver library.
>
> Like... drivers/video/fbdev/offb.c?

I'd probably reclassify drivers/video/fbdev/simplefb.c as a skeleton
and use it as a template for making device specific versions of it.

I don't see why there is so much resistance to just making device
specific fb drivers.  Whenever the KMS driver gets written just
disable the device specific fb driver in the build.


>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds



-- 
Jon Smirl
jonsm...@gmail.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.

Re: [linux-sunxi] GPL Violations round-up.

[Luc Verhaegen]

On Thu, Aug 28, 2014 at 04:07:11PM +0200, Michal Suchanek wrote:
> On 28 August 2014 14:51, Luc Verhaegen  wrote:
> > On Thu, Aug 28, 2014 at 02:29:46PM +0200, Michal Suchanek wrote:
> >
> > Facts please.
> >
> > I know Oliver got sent a 50usd A33 tablet just now, even though he got
> > told he would get an a23 tablet shortly before allwinner joined linaro.
> >
> > What else?
> >
> > Again, facts.
> >
> > We only get SDK sources (for some decreasing value thereof) from device
> > makers. Which of the docs that we have came from allwinner directly, and
> > didn't come from some other source?
> 
> Where did the a20 libnand and spl source come from?

I don't know, why don't you tell me?

Plus, if we have the source code for libnand for a20, then why is 
it listed on: http://linux-sunxi.org/A20#GPL_Violations

I believe that a A20 libnand blob was mentioned many times in this 
thread already. Why has this not been refuted by you or others?

Luc Verhaegen.

-- 
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: [PATCH 4/4] simplefb: add clock handling code

[Geert Uytterhoeven]

On Thu, Aug 28, 2014 at 3:22 PM, jonsm...@gmail.com  wrote:
>> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
>> driver, instead the bootloader should tell the kernel about these clocks.
>>
>> So the only point of discussion left seems to be how to do 2...
>
> Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
> whip together a device specific driver that claims the proper
> resources? And just implement the minimal about of fbdev possible?
> fbdev already is a driver library.

Like... drivers/video/fbdev/offb.c?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-- 
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] GPL Violations round-up.

[Michal Suchanek]

On 28 August 2014 14:51, Luc Verhaegen  wrote:
> On Thu, Aug 28, 2014 at 02:29:46PM +0200, Michal Suchanek wrote:
>> On 28 August 2014 13:57, Luc Verhaegen  wrote:
>> > On Thu, Aug 28, 2014 at 10:07:46AM +0300, Simos Xenitellis wrote:
>> >> It is indeed bad blood. Let's see a few:
>> >>
>> >> 1. "*Allwinner  does not actively
>> >> participate in or support this community. In fact, it is violating the
>> >> GPLv2 license  in several ways and
>> >> has so far not shown willingness to resolve this."*
>> >> Source: http://linux-sunxi.org/Main_Page (it is in bold, on the first page
>> >> of the Wiki!)
>> >
>> > Allwinner never has participated or supported this community so far. It
>>
>> This is simply not true.
>>
>> Allwinner has provided devboards and probably some docs and sources
>> upon request.
>
> Facts please.
>
> I know Oliver got sent a 50usd A33 tablet just now, even though he got
> told he would get an a23 tablet shortly before allwinner joined linaro.
>
> What else?
>
>> Of course, there is much left to be desired. Still this sentence alone
>> is false.
>
> Again, facts.
>
> We only get SDK sources (for some decreasing value thereof) from device
> makers. Which of the docs that we have came from allwinner directly, and
> didn't come from some other source?

Where did the a20 libnand and spl source come from?

Thanks

Michal

-- 
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: GPL Violations round-up

[Stefan Monnier]

> So please stop attacking AW in this way.

FWIW, I agree with Luc that it's important to bring this up and make
sure that there's some positive movement on that front.
Even if it's limited to splitting the blob into a "Free" glue code
linked to a binary blob.

And it doesn't have to get all fixed right away before we can do
anything else.  But there's a need to establish some understanding
between the two parties about this issue.


Stefan

-- 
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: [PATCH 4/4] simplefb: add clock handling code

[jonsm...@gmail.com]

On Thu, Aug 28, 2014 at 8:15 AM, Hans de Goede  wrote:
> Hi,
>
> On 08/27/2014 04:16 PM, Thierry Reding wrote:
>
> 
>
>>> The problems your talking about here all have to do with ordering how
>>> things are enabled, but what we're talking about here is keeping things
>>> enabled which are already enabled by the bootloader, so there is no
>>> ordering problem.
>>
>> See what I did there? I tricked you into saying what I've been saying
>> all along. =)
>
> He he :)
>
>> It's about keeping things enabled which have been enabled
>> by the bootloader. That's the root of the problem.
>
> Ok so we all seem to largely agree on most things here:
>
> 1) Somehow some clks must be marked used so as to not get disabled
> 2) We don't want to hardcode these clocks into the kernel (sunxi) clk
> driver, instead the bootloader should tell the kernel about these clocks.
>
> So the only point of discussion left seems to be how to do 2...

Wouldn't it be a lot simpler just to use existing fbdev (not KMS) and
whip together a device specific driver that claims the proper
resources? And just implement the minimal about of fbdev possible?
fbdev already is a driver library.

---

An independent issue is the early printk equivalent. For that you need
an address and the x/y layout

>
> 
>
>>> Hmm I see, in my mind the problem is not that the clk framework disables
>>> unused clocks, but that no one is marking the clocks in question as used.
>>> Someone should mark these clocks as used so that they do not get disabled.
>>>
>>> We could add a clk_mark_in_use function and have the simplefb patch call
>>> that instead of clk_prepare_and_enable, or maybe even better just only
>>> claim the clks and teach the clk framework to not disable claimed clk
>>> in its cleanup run. That would make it clear that simplefb is not enabling
>>> anything, just claiming resource its need to avoid them getting removed
>>> from underneath simplefb, would that work for you ?
>>
>> That would be more accurate, but it boils down to the same problem where
>> we still need a driver to claim the resources in some way whereas the
>> problem is fundamentally one where the bootloader should be telling the
>> kernel not to disable it. It's in fact the bootloader that's claiming
>> the resources.
>
> Yes, but those resources do not belong to the bootloader in a sense
> that traditional bootloader / firmware claimed resources (e.g. acpi
> reserved resources) do. These traditional resources are claimed for ever.
>
> Where as these resources are claimed by the bootloader to keep the simplefb
> it provides working, as soon as the simplefb is no longer used, they become
> unused.
>
> 
>
>>> No, there are a lot of other drivers which were written before someone
>>> decided that having 10-20 drivers which were 90% copy and paste of each
>>> other was a bad idea, but we're really going offtopic here.
>>
>> The copy and paste is for code that's platform specific. The clocks have
>> different names, resets are different, supplies are different. The fact
>> that many can currently use the same driver is likely just coincidence
>> rather than design and it's entirely possible that at some point they'll
>> add support for a more advanced feature that makes them incompatible
>> with the rest of the generic drivers. And then you have a big mess
>> because you need to add quirks all over the place.
>>
>> And this isn't all that far off-topic, since simplefb also needs to deal
>> with this kind of situation. And what I've been arguing is that in order
>> to really be generic it has to make assumptions, one of which is that it
>> uses only resources that it doesn't need to explicitly handle.
>
> I can understand that you're worried about generic ?hci drivers dealing with
> clocks / resets / etc. As there may be strict ordering requirements there,
> but for simplefb that is not the case.
>
> All we're asking for is for a way to communicate 2 things to the kernel:
>
> 1) These resources are in use (we are not asking the kernel to do anything
> with them, rather the opposite, we're asking to leave them alone so no
> ordering issues)
>
> 2) Tie these resources to simplefb so that the kernel can know when they
> are no longer in use, and it may e.g. re-use the memory
>
> To me the most logical and also most "correct" way of modelling this is to
> put the resources inside the simplefb dt node.
>
> 
>
>>> The key word here is "the used resources" to me this is not about simlefb
>>> managing resources, but marking them as used as long as it needs them, like
>>> it will need to do for the reserved mem chunk.
>>
>> The difference between the clocks and the memory resource is that the
>> driver needs to directly access the memory (it needs to map it and
>> provide a userspace mapping for it) whereas it doesn't need to touch the
>> clocks (except to workaround a Linux-specific implementation detail).
>
> Erm, no, the need to map the memory and the memory being a resource
> which may be released ar

Re: [linux-sunxi] GPL Violations round-up.

[Luc Verhaegen]

On Thu, Aug 28, 2014 at 02:29:46PM +0200, Michal Suchanek wrote:
> On 28 August 2014 13:57, Luc Verhaegen  wrote:
> > On Thu, Aug 28, 2014 at 10:07:46AM +0300, Simos Xenitellis wrote:
> >> It is indeed bad blood. Let's see a few:
> >>
> >> 1. "*Allwinner  does not actively
> >> participate in or support this community. In fact, it is violating the
> >> GPLv2 license  in several ways and
> >> has so far not shown willingness to resolve this."*
> >> Source: http://linux-sunxi.org/Main_Page (it is in bold, on the first page
> >> of the Wiki!)
> >
> > Allwinner never has participated or supported this community so far. It
> 
> This is simply not true.
> 
> Allwinner has provided devboards and probably some docs and sources
> upon request.

Facts please.

I know Oliver got sent a 50usd A33 tablet just now, even though he got 
told he would get an a23 tablet shortly before allwinner joined linaro. 

What else?

> Of course, there is much left to be desired. Still this sentence alone 
> is false.

Again, facts.

We only get SDK sources (for some decreasing value thereof) from device 
makers. Which of the docs that we have came from allwinner directly, and 
didn't come from some other source?

> As you might be aware they depend on the suppliers of the IP to
> provide the drivers or documentation. In the industry GPL violation is
> the standard. Often it is resolved not by opening the driver but by
> making a properly licensed glue. As has been seen with Mali this can
> somewhat help with porting as you can port the glue to newer kernel
> and reuse the blob but it does not provide much advantage for writing
> proper drivers. So by enforcing GPL you might get something that
> adheres to the letter of copyright laws and licenses but does not help
> you at all.

Allwinner has that source. Allwinner also integrated that code into the 
kernel and u-boot trees. Board makers which get those SDKs don't get 
that code. Allwinner seems to be the point where the violation happens.

Have you ever seen complete documentation? Have you ever seen code that 
tells you the whole story? You need both, but code gets you further, as 
you can keep it going. Going from incomplete/incorrect documentation 
alone very rarely leads to anything useful. When you have both, and they 
are contradictory, 9 out of 10 times, the code will be correct.

Actually, in the RadeonHD project, ATI was forced to accept an open 
source driver and to give us docs. They gave us twice 500pages of "this 
register, this bit" and then told us "good luck!". If we hadn't also 
been able to disassemble ATOMBios and see how things fit together, and 
what information in the docs was contradictory with actual code, we 
wouldn't have brought up the hw in the record time we did, and ATI 
would've been able to tell AMD in september 2007: "We told you so, this 
open source stuff doesn't work".

> You could argue that they could get IP for which sanely licensed
> driver or documentation is available but then again if you do have
> cost-effective providers of such IP please point them out.
> 
> I can't tell much about the AW's willingness (or lack of) to resolve
> the GPL issues but they are certainly not in the position in which
> resolving the issues is simple.

I believe that Allwinner can and will resolve this. I also know for a 
fact that GPLing some existing GPL violating code is not always 
possible. But there is a more than satisfactory way around that one.

Luc Verhaegen.

-- 
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] GPL Violations round-up.

[Michal Suchanek]

On 28 August 2014 13:57, Luc Verhaegen  wrote:
> On Thu, Aug 28, 2014 at 10:07:46AM +0300, Simos Xenitellis wrote:
>> It is indeed bad blood. Let's see a few:
>>
>> 1. "*Allwinner  does not actively
>> participate in or support this community. In fact, it is violating the
>> GPLv2 license  in several ways and
>> has so far not shown willingness to resolve this."*
>> Source: http://linux-sunxi.org/Main_Page (it is in bold, on the first page
>> of the Wiki!)
>
> Allwinner never has participated or supported this community so far. It

This is simply not true.

Allwinner has provided devboards and probably some docs and sources
upon request.

Of course, there is much left to be desired. Still this sentence alone is false.

> hadn't even shown the slightest signs of wanting to change this when
> that message was put up. And now that we got a few email addresses, it
> cannot be said that things have fundamentally improved, and that the
> above has become invalid.
>
> Allwinner is very much violating the GPL, and that is a cold hard fact.
> What is more, over the years, and people have been talking about this
> since early 2012, they have not shown any willingness to resolve this.
> Only this week did i get one statement that someone "will follow up",
> for whatever that means, as i haven't seen anything solid yet.

As you might be aware they depend on the suppliers of the IP to
provide the drivers or documentation. In the industry GPL violation is
the standard. Often it is resolved not by opening the driver but by
making a properly licensed glue. As has been seen with Mali this can
somewhat help with porting as you can port the glue to newer kernel
and reuse the blob but it does not provide much advantage for writing
proper drivers. So by enforcing GPL you might get something that
adheres to the letter of copyright laws and licenses but does not help
you at all.

You could argue that they could get IP for which sanely licensed
driver or documentation is available but then again if you do have
cost-effective providers of such IP please point them out.

I can't tell much about the AW's willingness (or lack of) to resolve
the GPL issues but they are certainly not in the position in which
resolving the issues is simple.

So please stop attacking AW in this way.

Thanks

Michal

-- 
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: [PATCH 4/4] simplefb: add clock handling code

[Hans de Goede]

Hi,

On 08/27/2014 04:16 PM, Thierry Reding wrote:



>> The problems your talking about here all have to do with ordering how
>> things are enabled, but what we're talking about here is keeping things
>> enabled which are already enabled by the bootloader, so there is no
>> ordering problem.
> 
> See what I did there? I tricked you into saying what I've been saying
> all along. =) 

He he :)

> It's about keeping things enabled which have been enabled
> by the bootloader. That's the root of the problem.

Ok so we all seem to largely agree on most things here:

1) Somehow some clks must be marked used so as to not get disabled
2) We don't want to hardcode these clocks into the kernel (sunxi) clk
driver, instead the bootloader should tell the kernel about these clocks.

So the only point of discussion left seems to be how to do 2...



>> Hmm I see, in my mind the problem is not that the clk framework disables
>> unused clocks, but that no one is marking the clocks in question as used.
>> Someone should mark these clocks as used so that they do not get disabled.
>>
>> We could add a clk_mark_in_use function and have the simplefb patch call
>> that instead of clk_prepare_and_enable, or maybe even better just only
>> claim the clks and teach the clk framework to not disable claimed clk
>> in its cleanup run. That would make it clear that simplefb is not enabling
>> anything, just claiming resource its need to avoid them getting removed
>> from underneath simplefb, would that work for you ?
> 
> That would be more accurate, but it boils down to the same problem where
> we still need a driver to claim the resources in some way whereas the
> problem is fundamentally one where the bootloader should be telling the
> kernel not to disable it. It's in fact the bootloader that's claiming
> the resources.

Yes, but those resources do not belong to the bootloader in a sense
that traditional bootloader / firmware claimed resources (e.g. acpi
reserved resources) do. These traditional resources are claimed for ever.

Where as these resources are claimed by the bootloader to keep the simplefb
it provides working, as soon as the simplefb is no longer used, they become
unused.



>> No, there are a lot of other drivers which were written before someone
>> decided that having 10-20 drivers which were 90% copy and paste of each
>> other was a bad idea, but we're really going offtopic here.
> 
> The copy and paste is for code that's platform specific. The clocks have
> different names, resets are different, supplies are different. The fact
> that many can currently use the same driver is likely just coincidence
> rather than design and it's entirely possible that at some point they'll
> add support for a more advanced feature that makes them incompatible
> with the rest of the generic drivers. And then you have a big mess
> because you need to add quirks all over the place.
> 
> And this isn't all that far off-topic, since simplefb also needs to deal
> with this kind of situation. And what I've been arguing is that in order
> to really be generic it has to make assumptions, one of which is that it
> uses only resources that it doesn't need to explicitly handle.

I can understand that you're worried about generic ?hci drivers dealing with
clocks / resets / etc. As there may be strict ordering requirements there,
but for simplefb that is not the case.

All we're asking for is for a way to communicate 2 things to the kernel:

1) These resources are in use (we are not asking the kernel to do anything
with them, rather the opposite, we're asking to leave them alone so no
ordering issues)

2) Tie these resources to simplefb so that the kernel can know when they
are no longer in use, and it may e.g. re-use the memory

To me the most logical and also most "correct" way of modelling this is to
put the resources inside the simplefb dt node.



>> The key word here is "the used resources" to me this is not about simlefb
>> managing resources, but marking them as used as long as it needs them, like
>> it will need to do for the reserved mem chunk.
> 
> The difference between the clocks and the memory resource is that the
> driver needs to directly access the memory (it needs to map it and
> provide a userspace mapping for it) whereas it doesn't need to touch the
> clocks (except to workaround a Linux-specific implementation detail).

Erm, no, the need to map the memory and the memory being a resource
which may be released are an orthogonal problem. E.g. a system with
dedicated framebuffer memory won't need to use a reserved main-memory
chunk, nor need to worry about returning that mem when simplefb is no
longer in use.

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] GPL Violations round-up.

[Luc Verhaegen]

On Thu, Aug 28, 2014 at 10:07:46AM +0300, Simos Xenitellis wrote:
> It is indeed bad blood. Let's see a few:
> 
> 1. "*Allwinner  does not actively
> participate in or support this community. In fact, it is violating the
> GPLv2 license  in several ways and
> has so far not shown willingness to resolve this."*
> Source: http://linux-sunxi.org/Main_Page (it is in bold, on the first page
> of the Wiki!)

Allwinner never has participated or supported this community so far. It 
hadn't even shown the slightest signs of wanting to change this when 
that message was put up. And now that we got a few email addresses, it 
cannot be said that things have fundamentally improved, and that the 
above has become invalid. 

Allwinner is very much violating the GPL, and that is a cold hard fact. 
What is more, over the years, and people have been talking about this 
since early 2012, they have not shown any willingness to resolve this. 
Only this week did i get one statement that someone "will follow up", 
for whatever that means, as i haven't seen anything solid yet.

> 2. "But with A80, Allwinner decided to step this up a notch, or two, or all
> the way to 11."
> Source: http://linux-sunxi.org/A80 (sensationalism)

http://linux-sunxi.org/UART#Reassemble_your_device

"Now you can do low level development on your tablet, even when on the 
move. Just don't bring it up in a conversation with normal people if you 
still want them to respect you afterwards."

> 3. "Over time, Allwinner has only increased the binary blobs present in
> their kernel trees, showing clearly that, even though Allwinner in the
> meantime joined Linaro, it is not progressing. Quite the opposite actually,
> and one has to worry about what value Linaro membership really has if a
> member is allowed to behave like this."
> Source: http://linux-sunxi.org/GPL_Violations (slander)

Let's see:
A10: -
A20: libnand
A31: $A20 + libisp (+ some touchscreen nonsense)
A23: $A31 + mdfs
A80: $A23 + libusb300 + lib_mipicsi2_vX + libfd + libdsi + libedp

If that is not "increasing", i would like to see your definition of
"increasing".

This A80 SDK is dated July 28th 2014 while Allwinner joined Linaro March 
3rd 2014. Plenty of time to resolve some issues there, i'd think.

I do not see how the above could be slander, with the above facts lined 
out that clearly.

> Your personal point of view (POV) is self-evident in your changes in the
> Wiki. If this was Wikipedia, you would have been locked out of the wiki
> already.

Well... Locking me out from the wiki is a bit tough in this case.

> Now, you are going to remove these fragments just to make the text your
> wrote appear "neutral".

The above is quite neutral. If you think it isn't, i can waste even 
more time on you and show you biased.

> But the damage has been done; there is so much bad blood that no matter
> what is the outcome, you personally will never be able to reconcile
> yourself with further sunxi development.

Come again?

> Simos

Simos who?

Luc Verhaegen.

-- 
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] A31 development board

[TsvetanUsunov]

>
> I ordered a devboard based on A31S (not A31) for 44USD, still waiting for 
> it: 
>
>
> http://www.aliexpress.com/item/quad-core-Allwinner-A31s-PCBA-board-1G-DDRIII-8G-NAND-FLASH-support-wifi-video-recording-playback/1989262018.html
>  
>
> I think A31S is a stripped down version of A31 (probably some parts of 
> the SOC are not activated/present). 
>
>
this one is with only 1GB RAM and 32bit data bus which will slow down twice 
the memory access, probably means no way to play 4K video
Tsvetan 

-- 
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: [PATCH 4/4] simplefb: add clock handling code

[Michal Suchanek]

On 28 August 2014 12:11, Thierry Reding  wrote:
> On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
>> On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
>> > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
>> > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
>> > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
>> > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
>> > [...]
>> > > > > > > Mike Turquette repeatedly said that he was against such a DT 
>> > > > > > > property:
>> > > > > > > https://lkml.org/lkml/2014/5/12/693
>> > > > > >
>> > > > > > Mike says in that email that he's opposing the addition of a 
>> > > > > > property
>> > > > > > for clocks that is the equivalent of regulator-always-on. That's 
>> > > > > > not
>> > > > > > what this is about. If at all it'd be a property to mark a clock 
>> > > > > > that
>> > > > > > should not be disabled by default because it's essential.
>> > > > >
>> > > > > It's just semantic. How is "a clock that should not be disabled by
>> > > > > default because it's essential" not a clock that stays always on?
>> > > >
>> > > > Because a clock that should not be disabled by default can be turned 
>> > > > off
>> > > > when appropriate. A clock that is always on can't be turned off.
>> > >
>> > > If a clock is essential, then it should never be disabled. Or we don't
>> > > share the same meaning of essential.
>> >
>> > Essential for the particular use-case.
>>
>> So, how would the clock driver would know about which use case we're
>> in? How would it know about which display engine is currently running?
>> How would it know about which video output is being set?
>>
>> Currently, we have two separate display engines, which can each output
>> either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
>> one of these combinations would require different clocks. What clocks
>> will we put in the driver? All of them?
>
> Ideally the solution wouldn't involve hard-coding this into the clock
> driver at all. There should be a way for firmware to communicate to the
> kernel that a given clock shouldn't be disabled. Then since firmware
> already knows what it set up it can tell the kernel to not touch those.
>

And that way is that it inserts into the simplefb node or whatever
node the list of clocks that it programmed in order to make the
framebuffer work. Do you know a better, more generic way than that?

Thanks

Michal

-- 
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] GPL Violations round-up.

[Paul Kocialkowski]

Le jeudi 28 août 2014 à 10:07 +0300, Simos Xenitellis a écrit :
> It is indeed bad blood. Let's see a few:

What exactly is your point here? Who cares that GPL violations
personally annoy people in addition to being damaging to our community?
And when that is the case, how exactly is it not legitimate and a
problem?

If we were discussing a strategy of how to get as much material as
possible in the shortest period of time from Allwinner, then maybe we
would consider not bringing up subjects that may be dead ends or would
potentially cause Allwinner to never talk to use again.

But what they're talking about here, through that collaboration promise
as well as their joining Linaro, is proper collaboration. The first step
in collaboration with our community is agreeing and respecting its
fundamental core principles, which they are not doing by repeatedly
violating the GPL.

Let's not reverse the situation here: Allwinner is attacking us by doing
this. We have every right to demand that Allwinner resolves the
situation and publicly state that they don't in the meantime.

A first step in the process of solving this situation would be for
Allwinner to just join in on the discussion and see what they can do.
This is how communities work.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution

Website: http://www.replicant.us/
Redmine: http://redmine.replicant.us/


signature.asc
Description: This is a digitally signed message part

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 05:42:21PM +0200, Maxime Ripard wrote:
> On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> > On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> > > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> > > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> > > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> > [...]
> > > > > > > Mike Turquette repeatedly said that he was against such a DT 
> > > > > > > property:
> > > > > > > https://lkml.org/lkml/2014/5/12/693
> > > > > > 
> > > > > > Mike says in that email that he's opposing the addition of a 
> > > > > > property
> > > > > > for clocks that is the equivalent of regulator-always-on. That's not
> > > > > > what this is about. If at all it'd be a property to mark a clock 
> > > > > > that
> > > > > > should not be disabled by default because it's essential.
> > > > > 
> > > > > It's just semantic. How is "a clock that should not be disabled by
> > > > > default because it's essential" not a clock that stays always on?
> > > > 
> > > > Because a clock that should not be disabled by default can be turned off
> > > > when appropriate. A clock that is always on can't be turned off.
> > > 
> > > If a clock is essential, then it should never be disabled. Or we don't
> > > share the same meaning of essential.
> > 
> > Essential for the particular use-case.
> 
> So, how would the clock driver would know about which use case we're
> in? How would it know about which display engine is currently running?
> How would it know about which video output is being set?
> 
> Currently, we have two separate display engines, which can each output
> either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> one of these combinations would require different clocks. What clocks
> will we put in the driver? All of them?

Ideally the solution wouldn't involve hard-coding this into the clock
driver at all. There should be a way for firmware to communicate to the
kernel that a given clock shouldn't be disabled. Then since firmware
already knows what it set up it can tell the kernel to not touch those.

Thierry


pgpxH2eOBYQ2e.pgp
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Thierry Reding]

On Wed, Aug 27, 2014 at 10:57:29PM +0200, Michal Suchanek wrote:
> Hello,
> 
> On 27 August 2014 17:42, Maxime Ripard  
> wrote:
> > On Wed, Aug 27, 2014 at 11:52:48AM +0200, Thierry Reding wrote:
> >> On Wed, Aug 27, 2014 at 10:45:26AM +0200, Maxime Ripard wrote:
> >> > On Wed, Aug 27, 2014 at 08:54:41AM +0200, Thierry Reding wrote:
> >> > > On Tue, Aug 26, 2014 at 11:02:48PM +0200, Maxime Ripard wrote:
> >> > > > On Tue, Aug 26, 2014 at 04:35:51PM +0200, Thierry Reding wrote:
> >> [...]
> >> > > > > > Mike Turquette repeatedly said that he was against such a DT 
> >> > > > > > property:
> >> > > > > > https://lkml.org/lkml/2014/5/12/693
> >> > > > >
> >> > > > > Mike says in that email that he's opposing the addition of a 
> >> > > > > property
> >> > > > > for clocks that is the equivalent of regulator-always-on. That's 
> >> > > > > not
> >> > > > > what this is about. If at all it'd be a property to mark a clock 
> >> > > > > that
> >> > > > > should not be disabled by default because it's essential.
> >> > > >
> >> > > > It's just semantic. How is "a clock that should not be disabled by
> >> > > > default because it's essential" not a clock that stays always on?
> >> > >
> >> > > Because a clock that should not be disabled by default can be turned 
> >> > > off
> >> > > when appropriate. A clock that is always on can't be turned off.
> >> >
> >> > If a clock is essential, then it should never be disabled. Or we don't
> >> > share the same meaning of essential.
> >>
> >> Essential for the particular use-case.
> >
> > So, how would the clock driver would know about which use case we're
> > in? How would it know about which display engine is currently running?
> > How would it know about which video output is being set?
> >
> > Currently, we have two separate display engines, which can each output
> > either to 4 different outputs (HDMI, RGB/LVDS, 2 DSI). Each and every
> > one of these combinations would require different clocks. What clocks
> > will we put in the driver? All of them?
> >
> 
> since simplefb cannot be extended how about adding, say, dtfb which
> claims the resources from dt and then instantiates a simplefb once the
> resources are claimed? That is have a dtfb which has the clocks
> assigned and has simplefb as child dt node.

I don't see how that changes anything. All you do is add another layer
of indirection. The fundamental problem remains the same and isn't
solved.

Thierry


pgppJQBEaKSr2.pgp
Description: PGP signature

Re: [linux-sunxi] [PATCH] sunxi: Generic A13_MID dram config, TZX-Q8-713B6 and TZX-Q8-713B7 support

[Paul Kocialkowski]

> This is not quite right. If you enable ODT, then the 'zq' settings are
> taken into use to configure the impedance. And the 0x7b (or 123 in the
> decimal format) is just the default reset value for the hardware
> register. It does not seem to make much sense, because it is pretty far
> away from the generally recommended impedance settings:
> 
> http://www.altera.com/literature/hb/external-memory/emi_plan_board_ddr2.pdf
> My understanding is that the 123 value has about the same meaning as
> 0xbadf00d or 0xdeadbeef, in the sense that they had to have some kind
> of default and they picked a nonsensical magic constant. I think that I
> have mentioned this to you in the irc chat earlier:
> http://irclog.whitequark.org/linux-sunxi/2014-08-24#9976940

Thanks for spotting this. To be honest, the A13-MID settings were simply
known to work on that TZX board, so I just moved them to a generic name
and didn't rewrite any of it. The dram settings I get out of meminfo are
a bit different (lower dram clk and odt_en disabled).

dram_clk  = 384
dram_type = 3
dram_rank_num = 1
dram_chip_density = 4096
dram_io_width = 16
dram_bus_width= 16
dram_cas  = 9
dram_zq   = 0x79
dram_odt_en   = 0
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10
dram_emr3 = 0x0

> More likely than not, if this configuration is really taken into use,
> then the DRAM reliability will become worse.
> 
> Luckily, the .odt_en settings are inert and have no effect on the A13
> hardware when used in the https://github.com/linux-sunxi/u-boot-sunxi/
> bootloader, as explained in:
> https://patchwork.ozlabs.org/patch/375959/

That is good to know.

> We just need to be really careful when moving all these piles of
> nonsensical junk DRAM settings to the mainline u-boot.

Would you advise reducing the dram clk to 384 instead of 432 in addition
to disabling odt? 432 seems to work just fine, even when running a full
xfce environment.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution

Website: http://www.replicant.us/
Redmine: http://redmine.replicant.us/


signature.asc
Description: This is a digitally signed message part

Re: [linux-sunxi] A31 development board

[Benjamin Henrion]

On Thu, Aug 28, 2014 at 10:14 AM, Siarhei Siamashka
 wrote:
> On Tue, 19 Aug 2014 09:06:46 -0700 (PDT)
> TsvetanUsunov  wrote:
>
>> Hi,
>>
>> we just assembled our first A31-SOM prototypes and they work fine with
>> Android.
>> http://olimex.wordpress.com/2014/08/19/our-first-a31-som-quad-core-arm-cortex-a7-system-on-module-prototypes-work-fine/
>> We have 3 spare A31-SOM-EVB to give away to interested Linux-Sunxi
>> developers who want to work to add A31 to Linux-Sunxi tree.
>
> Do I understand it right that these spare boards are specifically
> allocated for the developers willing to work on merging the sun6i
> code into the sunxi-3.4 kernel?
>
> Not everyone thinks that it is the best use of their time at this
> particular moment. But good luck with that and you are the boss :-)
>
>> More boards to give away will be available in September :-)
>
> This is a great news. The software support for A31 suffered
> significantly from not having an affordable development board.
> Thanks for taking the move towards finally solving this chicken/egg
> problem.

I ordered a devboard based on A31S (not A31) for 44USD, still waiting for it:

http://www.aliexpress.com/item/quad-core-Allwinner-A31s-PCBA-board-1G-DDRIII-8G-NAND-FLASH-support-wifi-video-recording-playback/1989262018.html

I think A31S is a stripped down version of A31 (probably some parts of
the SOC are not activated/present).

Best,

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-4148403
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

-- 
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] A31 development board

[TsvetanUsunov]

>
>
> Do I understand it right that these spare boards are specifically 
> allocated for the developers willing to work on merging the sun6i 
> code into the sunxi-3.4 kernel? 
>
>
I just write that we have few spare boards, if one want to develop but have 
no hardware we can provide
 

> Not everyone thinks that it is the best use of their time at this 
> particular moment. But good luck with that and you are the boss :-) 
>
>
I guess it's too much work to merge in Linux-Sunxi tree all A31 
differences, but this is not problem as there is alrernative SDK 
http://www.cnx-software.com/2014/08/20/allwinner-a31-android-linux-sdks-and-documentation-leaked/
 
which we successfully used to boot Linux on A31

Tsvetan

-- 
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] A31 development board

[TsvetanUsunov]

>
> Great news! 
>
> How are you wiring up the power for the I/O pins? 
> It'd be great if we had a seperate regulator for VCC-PF, 
> so we could run the SD card at 1.8V and do faster UHS-1 speeds. 
>
>
> Cheers 
> ChenYu 
>

hi
VCC-PF is connected to 3.3V
Tsvetan 

-- 
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] A31 development board

[Siarhei Siamashka]

On Tue, 19 Aug 2014 09:06:46 -0700 (PDT)
TsvetanUsunov  wrote:

> Hi,
> 
> we just assembled our first A31-SOM prototypes and they work fine with 
> Android.
> http://olimex.wordpress.com/2014/08/19/our-first-a31-som-quad-core-arm-cortex-a7-system-on-module-prototypes-work-fine/
> We have 3 spare A31-SOM-EVB to give away to interested Linux-Sunxi 
> developers who want to work to add A31 to Linux-Sunxi tree.

Do I understand it right that these spare boards are specifically
allocated for the developers willing to work on merging the sun6i
code into the sunxi-3.4 kernel?

Not everyone thinks that it is the best use of their time at this
particular moment. But good luck with that and you are the boss :-)

> More boards to give away will be available in September :-)

This is a great news. The software support for A31 suffered
significantly from not having an affordable development board.
Thanks for taking the move towards finally solving this chicken/egg
problem.

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

Re: [linux-sunxi] [PATCH] sunxi: Generic A13_MID dram config, TZX-Q8-713B6 and TZX-Q8-713B7 support

[Siarhei Siamashka]

On Tue, 26 Aug 2014 15:24:41 +0200
Paul Kocialkowski  wrote:

> Signed-off-by: Paul Kocialkowski 
> ---
>  board/sunxi/Makefile |4 +++-
>  board/sunxi/dram_a13_mid.c   |   31 
> --
>  board/sunxi/dram_sun5i_408_512_busw16_iow8.c |   31 
> ++
>  boards.cfg   |2 ++
>  4 files changed, 36 insertions(+), 32 deletions(-)
>  delete mode 100644 board/sunxi/dram_a13_mid.c
>  create mode 100644 board/sunxi/dram_sun5i_408_512_busw16_iow8.c
> 
> diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
> index fe5cb25..28b0f6a 100644
> --- a/board/sunxi/Makefile
> +++ b/board/sunxi/Makefile
> @@ -15,7 +15,7 @@ obj-$(CONFIG_A10_OLINUXINO_L)   += 
> dram_a10_olinuxino_l.o
>  obj-$(CONFIG_A10S_OLINUXINO_M)   += dram_a10s_olinuxino_m.o
>  obj-$(CONFIG_A13_OLINUXINO)  += dram_a13_olinuxino.o
>  obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
> -obj-$(CONFIG_A13_MID)+= dram_a13_mid.o
> +obj-$(CONFIG_A13_MID)+= dram_sun5i_408_512_busw16_iow8.o
>  obj-$(CONFIG_A20_OLINUXINO_L)+= dram_a20_olinuxino_l.o
>  obj-$(CONFIG_A20_OLINUXINO_L2)   += dram_a20_olinuxino_l2.o
>  obj-$(CONFIG_A20_OLINUXINO_M)+= dram_sun7i_384_1024_iow16.o
> @@ -85,6 +85,8 @@ obj-$(CONFIG_QT840A)+= 
> dram_sun7i_384_512_busw16_iow16.o
>  obj-$(CONFIG_R7DONGLE)   += dram_r7dongle.o
>  obj-$(CONFIG_SANEI_N90)  += dram_sanei_n90.o
>  obj-$(CONFIG_SEMITIME_G2)+= dram_semitime_g2.o
> +obj-$(CONFIG_TZX_Q8_713B6)   += dram_sun5i_408_512_busw16_iow8.o
> +obj-$(CONFIG_TZX_Q8_713B7)   += dram_sun5i_408_512_busw16_iow8.o
>  obj-$(CONFIG_UHOST_U1A)  += dram_sun4i_360_1024_iow8.o
>  obj-$(CONFIG_WEXLER_TAB_7200)+= dram_wexler_tab_7200.o
>  obj-$(CONFIG_WOBO_I5)+= dram_wobo_i5.o
> diff --git a/board/sunxi/dram_a13_mid.c b/board/sunxi/dram_a13_mid.c
> deleted file mode 100644
> index bc5cf75..000
> --- a/board/sunxi/dram_a13_mid.c
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -/* this file is generated, don't edit it yourself */
> -
> -#include 
> -#include 
> -
> -static struct dram_para dram_para = {
> - .clock = 408,
> - .type = 3,
> - .rank_num = 1,
> - .density = 2048,
> - .io_width = 8,
> - .bus_width = 16,
> - .cas = 9,
> - .zq = 123,
> - .odt_en = 1,
> - .size = 512,
> - .tpr0 = 0x42d899b7,
> - .tpr1 = 0xa090,
> - .tpr2 = 0x22a00,
> - .tpr3 = 0,
> - .tpr4 = 0,
> - .tpr5 = 0,
> - .emr1 = 0x4,
> - .emr2 = 0x10,
> - .emr3 = 0,
> -};
> -
> -unsigned long sunxi_dram_init(void)
> -{
> - return dramc_init(&dram_para);
> -}
> diff --git a/board/sunxi/dram_sun5i_408_512_busw16_iow8.c 
> b/board/sunxi/dram_sun5i_408_512_busw16_iow8.c
> new file mode 100644
> index 000..bc5cf75
> --- /dev/null
> +++ b/board/sunxi/dram_sun5i_408_512_busw16_iow8.c
> @@ -0,0 +1,31 @@
> +/* this file is generated, don't edit it yourself */
> +
> +#include 
> +#include 
> +
> +static struct dram_para dram_para = {
> + .clock = 408,
> + .type = 3,
> + .rank_num = 1,
> + .density = 2048,
> + .io_width = 8,
> + .bus_width = 16,
> + .cas = 9,
> + .zq = 123,
> + .odt_en = 1,

This is not quite right. If you enable ODT, then the 'zq' settings are
taken into use to configure the impedance. And the 0x7b (or 123 in the
decimal format) is just the default reset value for the hardware
register. It does not seem to make much sense, because it is pretty far
away from the generally recommended impedance settings:
http://www.altera.com/literature/hb/external-memory/emi_plan_board_ddr2.pdf
My understanding is that the 123 value has about the same meaning as
0xbadf00d or 0xdeadbeef, in the sense that they had to have some kind
of default and they picked a nonsensical magic constant. I think that I
have mentioned this to you in the irc chat earlier:
http://irclog.whitequark.org/linux-sunxi/2014-08-24#9976940

More likely than not, if this configuration is really taken into use,
then the DRAM reliability will become worse.

Luckily, the .odt_en settings are inert and have no effect on the A13
hardware when used in the https://github.com/linux-sunxi/u-boot-sunxi/
bootloader, as explained in:
https://patchwork.ozlabs.org/patch/375959/

We just need to be really careful when moving all these piles of
nonsensical junk DRAM settings to the mainline u-boot.

> + .size = 512,
> + .tpr0 = 0x42d899b7,
> + .tpr1 = 0xa090,
> + .tpr2 = 0x22a00,
> + .tpr3 = 0,
> + .tpr4 = 0,
> + .tpr5 = 0,
> + .emr1 = 0x4,
> + .emr2 = 0x10,
> + .emr3 = 0,
> +};
> +
> +unsigned long sunxi_dram_init(void)
> +{
> + return dramc_init(&dram_para);
> +}
> diff --git a/boards.cfg b/boards.cfg
> index 24edeb9..1124f74 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -468,6 +468,8 @@ Active  arm armv7

Re: [linux-sunxi] [PATCH] a13: TZX-Q8-713B7 support

[Siarhei Siamashka]

On Tue, 26 Aug 2014 14:08:08 +0200
Paul Kocialkowski  wrote:

> Signed-off-by: Paul Kocialkowski 
> ---
>  sys_config/a13/tzx-q8-713b7.fex |  653 
> +++
>  1 file changed, 653 insertions(+)
>  create mode 100644 sys_config/a13/tzx-q8-713b7.fex
> 
> diff --git a/sys_config/a13/tzx-q8-713b7.fex b/sys_config/a13/tzx-q8-713b7.fex
> new file mode 100644
> index 000..a123fd4
> --- /dev/null
> +++ b/sys_config/a13/tzx-q8-713b7.fex
> @@ -0,0 +1,653 @@
> +[product]
> +version = "1.0"
> +machine = "A13-EVB-V1.0"
> +
> +[target]
> +boot_clock = 1008
> +dcdc2_vol = 1400
> +dcdc3_vol = 1200

The dcdc3 voltage is suspiciously low. I understand that this is
probably intended to reduce power consumption, but you need to be
careful with DRAM reliability using these settings.

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

Re: [linux-sunxi] Overclocking A31 (higher than 1008MHz)

[Siarhei Siamashka]

On Mon, 25 Aug 2014 05:43:04 -0700 (PDT)
RFat  wrote:

> Hi all,
> 
> I am trying to overclock the A31 higher than 1008MHz

Are you fine with the deterioration of reliability and/or overheating
under high load?

> and I am getting  deterioration in performance.
> 
> The way I work is execute a small program from u-boot which redefines the N 
> multiplayer of PLL1 and then runs some CPU-intentive routine (to measure 
> performance).
> 
> Here are the results I get (the N multiplier is given in the small brackets 
> starting from 18):
> 
> CPU Freq = 864Mhz (18)
> run in 10Hz, 94ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:18 Sigma:0 Lock:0 Freq:432Mhz coreclk:864Mhz
> CPU Freq = 912Mhz (19)
> run in 11Hz, 89ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:19 Sigma:0 Lock:0 Freq:456Mhz coreclk:912Mhz
> CPU Freq = 960Mhz (20)
> run in 11Hz, 85ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:20 Sigma:0 Lock:0 Freq:480Mhz coreclk:960Mhz
> CPU Freq = 1008Mhz (21)
> run in 12Hz, 81ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:21 Sigma:0 Lock:0 Freq:504Mhz coreclk:1008Mhz
> CPU Freq = 1056Mhz (22)
> run in 12Hz, 77ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:22 Sigma:0 Lock:0 Freq:528Mhz coreclk:1056Mhz
> CPU Freq = 1104Mhz (23)
> run in 9Hz, 101ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:23 Sigma:0 Lock:0 Freq:552Mhz coreclk:1104Mhz
> CPU Freq = 1152Mhz (24)
> run in 9Hz, 101ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:24 Sigma:0 Lock:0 Freq:576Mhz coreclk:1152Mhz
> CPU Freq = 1200Mhz (25)
> run in 9Hz, 101ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:25 Sigma:0 Lock:0 Freq:600Mhz coreclk:1200Mhz
> CPU Freq = 1248Mhz (26)
> run in 9Hz, 101ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:26 Sigma:0 Lock:0 Freq:624Mhz coreclk:1248Mhz
> CPU Freq = 1296Mhz (27)
> run in 9Hz, 101ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:27 Sigma:0 Lock:0 Freq:648Mhz coreclk:1296Mhz
> CPU Freq = 1344Mhz (28)
> run in 9Hz, 101ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:28 Sigma:0 Lock:0 Freq:672Mhz coreclk:1344Mhz
> CPU Freq = 1392Mhz (29)
> run in 9Hz, 101ms
> PLL1 is ENABLED  P:2 M:1 K:3 N:29 Sigma:0 Lock:0 Freq:696Mhz coreclk:1392Mhz
> 
> As you can see, after 1008 (or 1056) there's a _decrease_ in performance.

I can see that the performance flattens out and remains at the same
101ms level for your CPU-intensive routine.

If you are running the code in u-boot from SRAM and the L1 cache is not
enabled, then the instructions fetch may become a bottleneck. 

> Does anyone knows how higher performance can be achieved?

Maybe buy a different higher performance SoC or better optimize the
software?

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

Re: [linux-sunxi] GPL Violations round-up.

[Simos Xenitellis]

It is indeed bad blood. Let's see a few:

1. "*Allwinner  does not actively
participate in or support this community. In fact, it is violating the
GPLv2 license  in several ways and
has so far not shown willingness to resolve this."*
Source: http://linux-sunxi.org/Main_Page (it is in bold, on the first page
of the Wiki!)

2. "But with A80, Allwinner decided to step this up a notch, or two, or all
the way to 11."
Source: http://linux-sunxi.org/A80 (sensationalism)

3. "Over time, Allwinner has only increased the binary blobs present in
their kernel trees, showing clearly that, even though Allwinner in the
meantime joined Linaro, it is not progressing. Quite the opposite actually,
and one has to worry about what value Linaro membership really has if a
member is allowed to behave like this."
Source: http://linux-sunxi.org/GPL_Violations (slander)

Your personal point of view (POV) is self-evident in your changes in the
Wiki. If this was Wikipedia, you would have been locked out of the wiki
already.
Now, you are going to remove these fragments just to make the text your
wrote appear "neutral".
But the damage has been done; there is so much bad blood that no matter
what is the outcome, you personally will never be able to reconcile
yourself with further sunxi development.

Simos


On Wed, Aug 27, 2014 at 11:57 PM, Luc Verhaegen  wrote:

> On Wed, Aug 27, 2014 at 11:13:36PM +0300, Simos Xenitellis wrote:
> > I think that there is so much bad blood that there is no way that Luc
> would
> > happily code/contribute in the future for the sun[4-7]i family of SoCs.
> > This family would be a dead-end for him, and perhaps another family might
> > be more appropriate.
> > I think that no matter what the outcome of this thread is, the bad blood
> > will remain and appear again for some other issues in the future.
> >
> > Simos
>
> Bad blood? Me talking about GPL violations is just bad blood?
>
> Not "if $vendor is serious about open source, then finally adhering to
> the GPL would be the best (and a required) start to showing $vendor
> commitment to open source". Nono, apparently, all a vendor has to do is
> state their willingness to cooperate, and give only very vague
> statements about how they see that cooperation work. And anyone who
> interferes with that, and dares to mention minor and absolutely
> inconsequential legal issues, he should be surreptitiously told to go
> play somewhere else?
>
> What?
>
> Luc Verhaegen.
>

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