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

[Thierry Reding]

On Mon, Sep 29, 2014 at 05:11:01PM +0100, Mark Brown wrote:
> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> 
> > > With that said I think that Luc's approach is very sensible. I'm not
> > > sure what purpose in the universe DT is supposed to serve if not for
> > > _this_exact_case_. We have a nice abstracted driver, usable by many
> > > people. The hardware details of how it is hooked up at the board level
> > > can all be hidden behind stable DT bindings that everyone already uses.
> 
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> 
> Not really thought this through fully yet but would having phandles to
> the relevant devices do the job?  Kind of lines up with Grant's idea of
> having dummy drivers.

One of the arguments that came up during the discussion of the sunxi
patches is that simplefb is going to be used precisely because there is
no real driver for the display part of the SoC yet and nobody knows what
the binding will look like. So there's nothing to point at currently and
for the same reason having a dummy driver won't work. There's simply no
definition of what resources are needed.

> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> 
> We might want to do that in the future, though it's not always the case
> that reset is the lowest power state.

That proves my point. If we ever decide to assert resets by default
we'll have yet another subsystem that can potentially break existing
DTs.

In the end it brings us back to the very fundamental principles of DT
that's been causing so much pain. For things to work properly and in a
stable way you have to get the bindings right and complete from the
start. That is, it needs to describe every aspect of the hardware block
and all links to other components.

But there is no way you can do that for a virtual device like simplefb
because it is a generic abstraction for hardware that varies wildly. The
only way to make it work is to abstract away all the resource management
and consider it to be done elsewhere.

> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> One thing that makes me a bit nervous about this approach in the context
> of the regulator API is the frequency with which one finds shared
> supplies.  I'm not sure if it's actually a big problem in practice but
> it makes me worry a bit.  We could probably just do something like make
> refcounting down to zero not actually disable anything for standard
> regulators to deal with it which might be an idea anyway in the context
> of this sort of dodge.

Yes, that's sort of how I expected clk_ignore_unused to work. The way I
understood it, it would cause all unused clocks to be ignored (that is
stay enabled if they are).

Of course as Geert pointed out in another subthread, taking this all the
way means that we have to disable all power man

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

[Thierry Reding]

On Tue, Sep 30, 2014 at 12:02:50AM +0200, Luc Verhaegen wrote:
> On Mon, Sep 29, 2014 at 06:58:42PM +0200, Luc Verhaegen wrote:
> > 
> > In the 2nd round of this discussion, i stated that another fb or even a 
> > drm driver altogether seemed to be the sensible way out of this mess.
> > 
> > I suggest drm_rescue.
> > 
> > Very early on, now almost two months back, i used the word "denialfb".
> > rpifb is the real name of this thing though, but then the dt binding 
> > names would have to change and whatnot.
> > 
> > I don't get the resistance, at least not from a technical point of view. 
> > And i do not care enough to get properly involved in this pointless and 
> > endless discussion. drm_rescue it is.
> > 
> > Luc Verhaegen.
> 
> So Thierry, let's review what we have achieved here.
> 
> 1) you keep simplefb absolutely true to the name. Congratulations.
> 2) Simplefb will only have a single user: the rpi. As the only other 
> users i can think of, which does not have a full driver and which does 
> not have clocks automatically disabled, are discrete cards. And they do 
> not really tend to happen with dt or platform devices.
> 3) a competing driver will be created, which will do these dt-ishy 
> things.

You clearly haven't bothered to even try and understand what I wanted to
achieve. If you had you'd realize that creating a competing driver isn't
going to change anything.

> 4) it's just a matter of time before the rpi either gets a full driver, 
> or switches over to the driver that everyone else is actually using. And 
> then the misnomer gets deprecated.
> 
> Was that the outcome you were looking for? I think not.

I had, perhaps naively, expected that you guys would be willing to look
beyond your own nose. You clearly aren't. You've been outright
dismissing any proposals beyond what you originally posted.

You keep bringing up the Raspberry Pi for some reason and suggest that
it is somehow inferior to sunxi. What makes you think it's less entitled
to be supported on Linux than sunxi? I don't care about the Raspberry Pi
and I equally don't care about sunxi. I don't own a Raspberry Pi and I
don't own any Allwinner hardware. What I do care about is Linux and I
want it to work well for all SoCs equally.

Perhaps if you could put aside your crusade against the Raspberry Pi for
just a second you'll realize that we're all on the same team. This isn't
a competition and I'm not trying to put a spoke in your wheel. On the
contrary, I'm actually trying to help you.

Thierry


pgpqfdQJ8nL83.pgp
Description: PGP signature

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > > > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > > > [...]
> > > > > > simplefb doesn't deal at all with hardware details. It simply uses 
> > > > > > what
> > > > > > firmware has set up, which is the only reason why it will work for 
> > > > > > many
> > > > > > people. What is passed in via its device tree node is the minimum 
> > > > > > amount
> > > > > > of information needed to draw something into the framebuffer. Also 
> > > > > > note
> > > > > > that the simplefb device tree node is not statically added to a DTS 
> > > > > > file
> > > > > > but needs to be dynamically generated by firmware at runtime.
> > > > > 
> > > > > Which makes the whole even simpler, since the firmware already knows
> > > > > all about which clocks it had to enable.
> > > > 
> > > > It makes things very complicated in the firmware because it now needs to
> > > > be able to generate DTB content that we would otherwise be able to do
> > > > much easier with a text editor.
> > > 
> > > Didn't you just say that it was dynamically generated at runtime? So
> > > we can just ignore the "text editor" case.
> > 
> > Perhaps read the sentence again. I said "that we would *otherwise* be
> > able to do much easier with a text editor.".
> > 
> > My point remains that there shouldn't be a need to generate DTB content
> > of this complexity at all.
> > 
> > > > Why do you think what I proposed isn't going to work or be reliable?
> > > > I don't see any arguments in the thread that would imply that.
> > > 
> > > The fact that it broke in the first place?
> > 
> > That's exactly the point. And it's going to break again and again as
> > simplefb is extended with new things. Generally DT bindings should be
> > backwards compatible. When extended they should provide a way to fall
> > back to a reasonable default. There's simply no way you can do that
> > with simplefb.
> 
> This one *is* backward compatible. It doesn't even change the simplefb
> behaviour, compared to what it was doing before, if you don't have
> this clocks property. What can be a more reasonable default that the
> way it used to behave?

My point is that if we decide not to consider all resources handled by
firmware then we need to go all the way. At that point you start having
problems as evidenced by the Snow example.

> > What happened in the Snow example is that regulators that were
> > previously on would all of a sudden be automatically disabled on boot
> > because there was now a driver that registered them with a generic
> > framework.
> > 
> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> >
> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> Sure, we can add any resources we will need. Regulators, reset lines,
> pm domains, allocated memory, but I'm not really sure this is what you
> want, right?

No it's not what I want. *You* want to add resource management to this
driver. What I'm saying is that if we start adding clocks then we can no
longer say no to resets or regulators or power domains either.

> > > > > You know that you are going to call that for regulator, reset, power
> > > > > domains, just as you would have needed to with the proper API, unless
> > > > > that with this kind of solution, you would have to modify *every*
> > > > > framework that might interact with any resource involved in getting
> > > > > simplefb running?
> > > > 
> > > > We have to add handling for every kind of resource either way. Also if
> > > > this evolves into a common pattern we can easily wrap it up in a single
> > > > function call.
> > > 
> > > Unless that in one case, we already have everything needed to handle
> > > everything properly, and in another, you keep hacking more and more
> > > into the involved frameworks.
> > 
> > This is a fundamental issue that we are facing and I'm trying to come up
> > with a solution that is future-proof and will work for drivers other
> > than simplefb.
> > 
> > Just because we currently lack this functionality doesn't make it a hack
> > trying to add it.
> 
> Or maybe it's just showing that the trend to rely more and more on the
> firmware is a bad idea?

If you think it's a bad idea to rely on firmware then you shouldn't be
using

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 04:55:17PM +0100, Mark Brown wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
[...]
> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> 
> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> So long as we're ensuring that when we don't start supporting resources
> without DT additions or at least require DT additions to actively manage
> them (which can then include simplefb hookup) we should be fine.

I'm not sure I understand what you mean. If we add a driver for the PMIC
that exposes these regulators and then add a DT node for the PMIC, we'd
still need to fix the firmware to generate the appropriate DT properties
to allow simplefb to enable the regulators.

So unless firmware is updated at the same time, regulators will get
disabled because they are unused.

Thierry


pgp7VvxO9FEQu.pgp
Description: PGP signature

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 05:57:18PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > > >> Plus, speaking more specifically about the clocks, that won't 
> > > > > >> prevent
> > > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > > >> call from another driver.
> > > > > 
> > > > > > Furthermore isn't it a bug for a driver to call clk_disable() 
> > > > > > before a
> > > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > > enable per-user clocks and as I understand it they will specifically
> > > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > > still keeping them on via their own referenc.
> > > > > 
> > > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > > 
> > > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > > its parents)
> > > > > if the clock subsystem thinks there are no other users, which is what 
> > > > > will
> > > > > happen here.
> > > > 
> > > > Right. I'm not sure this is really applicable to this situation, though.
> > > 
> > > It's actually very easy to do. Have a driver that probes, enables its
> > > clock, fails to probe for any reason, call clk_disable in its exit
> > > path. If there's no other user at that time of this particular clock
> > > tree, it will be shut down. Bam. You just lost your framebuffer.
> > > 
> > > Really, it's just that simple, and relying on the fact that some other
> > > user of the same clock tree will always be their is beyond fragile.
> > 
> > Perhaps the meaning clk_ignore_unused should be revised, then. What you
> > describe isn't at all what I'd expect from such an option. And it does
> > not match the description in Documentation/kernel-parameters.txt either.
> 
> Well, it never says that it also prevent them from being disabled
> later on. But it's true it's not very explicit.

It says:

Keep all clocks already enabled by bootloader on,
even if no driver has claimed them. ...

There's no "until" or anything there, so I interpret that as
indefinitely.

> > > > Either way, if there are other users of a clock then they will just as
> > > > likely want to modify the rate at which point simplefb will break just
> > > > as badly.
> > > 
> > > And this can be handled just as well. Register a clock notifier,
> > > refuse any rate change, done. But of course, that would require having
> > > a clock handle.
> > > 
> > > Now, how would *you* prevent such a change?
> > 
> > Like I said in the other thread. If you have two drivers that use the
> > same clock but need different frequencies you've lost anyway.
> 
> Except that the driver that has the most logic (ie not simplefb) will
> have a way to recover and deal with that.

You're making an assumption here. Why would the driver have such logic
if nothing ever prevented it from setting the rate properly before.

> But sure, you can still try to point new issues, get an obvious and
> robust solution, and then discard the issue when the solution doesn't
> go your way...

And you've already proven that you're completely unwilling to even
consider any other solution than what was originally proposed, so I
really don't see how discussing this further with you is going to be
productive.

Thierry


pgpHQW_Zr8ZNU.pgp
Description: PGP signature

Re: [linux-sunxi] A80 mixed OS (Linux / RTOS)

[Quink]

Such a big plan. I just did a small project with (Real-time patch for linux
kernel) + (processor affinity) + (super loop) on A20.
Since A20 has two A7, a real time process can occupy a processor and leave
the other for other tasks. With out a working
main line kernel, it seems like you have a lot of work to do to customize
the kernel.

On Tue, Sep 30, 2014 at 4:46 AM, javqui  wrote:

> Hi,
> I'm working on a couple of projects requiring the classic Micro controller
> features (low power, deterministic real time processing) and the classic
> UX, flexibility and functionality of Linux /android.
>
> Most SoCs today provide many high level external hardware interfaces (like
> Camera, USB, HDMI, etc) but some projects require additional drivers and
> interfaces to handle different external hardware. Usually we solve the
> interconnectivity with extra MCUs, FPGAs or other specialized chip
> interfaces available.
>
> Sometimes, we design product boards with two solutions: a Cortex A SoC
> like Allwinner/rockchip/Omap series and a small MCU Cortex M like the STM32
> series, but with a powerful A80, it could change forever.
>
> I will receive my first Optimus board soon, and I want to customize the
> kernel to create a classic Linux running on the powerful 4x A15+ GPU and
> Nucleus (or Free RTOS) on one or two of the A7 of the Allwinner A80 Soc. (I
> made similar kernel works with MTK SoCs in the past, but never try to run
> two operating systems in the same chip at the same time)
>
> Both projects require continuous operation and deterministic real time
> response on the low power processor(s) (RTOS on A7).
> User interaction (Linux on the A15 + GPU side ) is only eventual, so
> termal issues by running almost all processors at the same time
> occasionally,  should not be a problem.
>
> If anyone anticipate a significant barrier to build a kernel of this type,
> please share it here, I will really appreciate. I will share the results
> and evaluation test here
>
> Additionally I will really appreciate if someone could help me to get the
> A80 user manual, (please contact me by email). Both projects require access
> to low level A80 features for special hardware interfaces and the user
> manual is a must for both projects and future product projects related with
> the A80. I want to switch almost all my projects to Allwinner A80.
>
> Javqui
>
> --
> 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] Re: [PATCH 4/4] simplefb: add clock handling code

[Julian Calaby]

Hi Thierry,

On Tue, Sep 30, 2014 at 1:19 AM, Thierry Reding
 wrote:
> On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
>> Hi Thierry,
>>
>> On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
>>  wrote:
>> > On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
>> >> Hi Thierry,
>> >
>> > If you address people directly please make sure they are in the To:
>> > line. Or at least Cc.
>>
>> Sorry about that, the mailing list I received this through (Google
>> Groups based) generally strips to: and CC: lines, so my mail client
>> (Gmail) doesn't do it automatically. I'm still getting used to it.
>
> Yeah, I wish mailing lists would stop doing that.
>
>> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> >>  wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> >> > simplefb doesn't deal at all with hardware details. It simply uses 
>> >> >> > what
>> >> >> > firmware has set up, which is the only reason why it will work for 
>> >> >> > many
>> >> >> > people. What is passed in via its device tree node is the minimum 
>> >> >> > amount
>> >> >> > of information needed to draw something into the framebuffer. Also 
>> >> >> > note
>> >> >> > that the simplefb device tree node is not statically added to a DTS 
>> >> >> > file
>> >> >> > but needs to be dynamically generated by firmware at runtime.
>> >> >>
>> >> >> Which makes the whole even simpler, since the firmware already knows
>> >> >> all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> As far as the kernel is concerned, this is a solved problem.
>> >
>> > It's not completely solved. There's still the issue of no generic way to
>> > specify regulators like you can do for clocks, resets or power domains.
>> > But the kernel isn't the real issue here. The issue is the firmware that
>> > now has to go out of its way not only to initialize display hardware but
>> > also create device tree content just to make Linux not turn everything
>> > off.
>>
>> My point is that the firmware is going to be doing complicated stuff
>> already, adding and using some helpers to configure a device tree node
>> is relatively simple in comparison to dealing with the actual
>> hardware. It wouldn't surprise me if u-boot, for example, ended up
>> with a set of functions to handle this exact case as more graphics
>> hardware gets brought up.
>
> Not all firmware is based on U-Boot. Essentially whatever binding
> changes we make will need to be implemented in all firmware. And the
> complexity isn't so much about writing the actual DT data, but more
> about figuring out which data to write. Every firmware image needs to
> know exactly which clocks and other resources to transcribe for a given
> board. It'll essentially need to contain some sort of "driver" for each
> device that parses a DTB, correlates the data to what it knows of the
> device internals and write a subset of that data back into the DTB in a
> slightly different format. That's just whacky.
>
> DT was meant to simplify things.

Ok, fair enough, while it's a tempting solution - it makes the kernel
end of things nice and simple, it's probably not completely scalable.
U-boot definitely does have "drivers" for the hardware it supports,
but we can't expect every bootloader to do that.

>> >> Firmware is going to be doing some dark magic to set up the hardware
>> >> to be a dumb frame buffer and some other stuff to add the simplefb
>> >> device node - so by this point, adding the clocks (or whatever)
>> >> required by the hardware should be fairly uncomplicated - the firmware
>> >> already knows the hardware intimately. As for the actual device tree
>> >> manipulations, U-boot (or whatever) will probably just grow some
>> >> helper functions to make this simple.
>> >
>> > Have you looked at the code needed to do this? It's not at all trivial.
>> > And the point is really that all this information is there already, so
>> > we're completely duplicating this into a dynamically created device tree
>> > node and for what reason? Only to have one driver request all these
>> > resources and have them forcefully released a few seconds later.
>> >
>> >> Alternatively, it could simply add the relevant data to an existing
>> >> device node and munge it's compatible property so simplefb picks it
>> >> up.
>> >
>> > Yes, I think that'd be a much better solution. Of course it's going to
>> > be very difficult to make that work with a generic driver because now
>> > that generic driver needs to parse the DT binding for any number of
>> > "compatible" devices.
>>
>> Not necessarily.
>>
>> The patch that started this discussion can work with any number of
>> clocks specified in a "clocks" property. 

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

[Luc Verhaegen]

On Mon, Sep 29, 2014 at 06:58:42PM +0200, Luc Verhaegen wrote:
> 
> In the 2nd round of this discussion, i stated that another fb or even a 
> drm driver altogether seemed to be the sensible way out of this mess.
> 
> I suggest drm_rescue.
> 
> Very early on, now almost two months back, i used the word "denialfb".
> rpifb is the real name of this thing though, but then the dt binding 
> names would have to change and whatnot.
> 
> I don't get the resistance, at least not from a technical point of view. 
> And i do not care enough to get properly involved in this pointless and 
> endless discussion. drm_rescue it is.
> 
> Luc Verhaegen.

So Thierry, let's review what we have achieved here.

1) you keep simplefb absolutely true to the name. Congratulations.
2) Simplefb will only have a single user: the rpi. As the only other 
users i can think of, which does not have a full driver and which does 
not have clocks automatically disabled, are discrete cards. And they do 
not really tend to happen with dt or platform devices.
3) a competing driver will be created, which will do these dt-ishy 
things.
4) it's just a matter of time before the rpi either gets a full driver, 
or switches over to the driver that everyone else is actually using. And 
then the misnomer gets deprecated.

Was that the outcome you were looking for? I think not.

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] sunxi: Fix gmac not working reliable on the Bananapi

[Siarhei Siamashka]

On Mon, 29 Sep 2014 20:16:35 +0200
Karsten Merker  wrote:

> On Mon, Sep 29, 2014 at 09:13:37AM +0300, Siarhei Siamashka wrote:
> 
> > On Sun, 28 Sep 2014 20:13:21 +0200
> > Hans de Goede  wrote:
> > 
> > > In order for the gmac nic to work reliable on the Bananapi, we need to 
> > > poke
> > > these 2 undocumented bits in the gmac clk register. Since these are
> > > undocumented, this commit only sets these bits on the Bananapi for now.
> > > 
> > > I'll contact Allwinner to try and get these bits documented, once they
> > > are documented we can hopefully replace this hack with a better patch.
> > 
> > Could you please provide a bit more details in the commit message?
> > What are the symptoms of the problem?
> 
> Without the patch, u-boot on the BananaPi shows massive packet loss
> on every network activity.  The packet loss is so extreme that it is
> actually impossible to boot a kernel by tftp because u-boot gives up. 
> The mainline kernel has (once booted) shown similar problems on the
> BananaPi.
>
> > How did you come to the idea to poke these bits?
> 
> The linux 3.4 kernel from https://github.com/LeMaker/linux-bananapi
> (which is a patched linux-sunxi.org 3.4 kernel) does not show this
> problem, so we started looking into what is different there, and the
> relevant change that was found was setting these particular
> undocumented bits.

Thanks for the detailed explanations. They would look really great in
the commit message.

> > Does the GMAC driver in the linux kernel need a similar 
> > fix/workaround?
> 
> Not as far as I can see - once u-boot has set these two bits during
> system initialization, the mainline kernel works fine without
> any changes. 

OK. I just wonder if it is a good idea for the kernel to rely on
these bits being set appropriately by the bootloader. Not that it
has anything to do with u-boot.

> > Also as mentioned in another e-mail
> > http://lists.denx.de/pipermail/u-boot/2014-September/190096.html
> > u-boot configures the "912MHz @1.4V" CPU clock frequency/voltage
> > setup for sun7i hardware. And according to the information from Tony
> > Zhang, this is supposed to be unreliable for the Banana Pi. So what
> > happens to this GMAC bug if you just increase the dcdc2 voltage in
> > u-boot (or reduce the CPU clock frequency)?
> 
> I can test that if you could tell me what would have to be changed
> in u-boot to do that.

The dcdc2 voltage is set here (under the CONFIG_AXP209_POWER ifdef):
   
http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=2179e234e21d67b0fec064de792fca175db90ca5;hb=be9f643ae6aa9044c60fe80e3a2c10be8371c692#l140
Right now it is set to 1400, which means 1.4V (and the voltage can
be changed in 0.025V steps).

The CPU clock frequency for sun7i is set here:
   
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/sun7i.h;h=a902b845744707e64fb5a064c6039bc93b0150d9;hb=be9f643ae6aa9044c60fe80e3a2c10be8371c692#l16
Right now it is set to 912MHz

This CPU clock frequency/voltage pair is then just used unmodified by
the mainline kernel (until we get proper cpufreq support later). So it
makes a lot of sense to be sure that it is sufficiently reliable on
every Allwinner A20 device. You can try to increase the dcdc2 voltage
or reduce the CPU clock frequency and check if the Banana Pi reliability
problems disappear.

By the way, the dcdc2 voltage is already set to the maximum, which is
specified in the datasheet. You can have a look at VDD-CPU limits in
   
https://github.com/allwinner-zh/documents/blob/master/A20/A20%20Datasheet%20V1.4%2020131230.pdf
And VDD-CPU is provided from dcdc2, as can be seen, for example, in the
A20-OLINUXINO-MICRO schematics (the Banana Pi does not seem to have its
schematics document in public access, but all A20 devices have it
designed in the same way):
   
https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A10-OLinuXino-MICRO/A20-OLINUXINO-MICRO_4GB_Rev_F1.pdf

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

[linux-sunxi] A80 mixed OS (Linux / RTOS)

[javqui]

Hi,
I'm working on a couple of projects requiring the classic Micro controller 
features (low power, deterministic real time processing) and the classic 
UX, flexibility and functionality of Linux /android.

Most SoCs today provide many high level external hardware interfaces (like 
Camera, USB, HDMI, etc) but some projects require additional drivers and 
interfaces to handle different external hardware. Usually we solve the 
interconnectivity with extra MCUs, FPGAs or other specialized chip 
interfaces available.

Sometimes, we design product boards with two solutions: a Cortex A SoC like 
Allwinner/rockchip/Omap series and a small MCU Cortex M like the STM32 
series, but with a powerful A80, it could change forever.

I will receive my first Optimus board soon, and I want to customize the 
kernel to create a classic Linux running on the powerful 4x A15+ GPU and 
Nucleus (or Free RTOS) on one or two of the A7 of the Allwinner A80 Soc. (I 
made similar kernel works with MTK SoCs in the past, but never try to run 
two operating systems in the same chip at the same time)

Both projects require continuous operation and deterministic real time 
response on the low power processor(s) (RTOS on A7). 
User interaction (Linux on the A15 + GPU side ) is only eventual, so termal 
issues by running almost all processors at the same time occasionally,  
should not be a problem.

If anyone anticipate a significant barrier to build a kernel of this type, 
please share it here, I will really appreciate. I will share the results 
and evaluation test here

Additionally I will really appreciate if someone could help me to get the 
A80 user manual, (please contact me by email). Both projects require access 
to low level A80 features for special hardware interfaces and the user 
manual is a must for both projects and future product projects related with 
the A80. I want to switch almost all my projects to Allwinner A80.

Javqui

-- 
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] sunxi: Fix gmac not working reliable on the Bananapi

[jonsm...@gmail.com]

On Mon, Sep 29, 2014 at 2:16 PM, Karsten Merker  wrote:
> On Mon, Sep 29, 2014 at 09:13:37AM +0300, Siarhei Siamashka wrote:
>
>> On Sun, 28 Sep 2014 20:13:21 +0200
>> Hans de Goede  wrote:
>>
>> > In order for the gmac nic to work reliable on the Bananapi, we need to poke
>> > these 2 undocumented bits in the gmac clk register. Since these are
>> > undocumented, this commit only sets these bits on the Bananapi for now.
>> >
>> > I'll contact Allwinner to try and get these bits documented, once they
>> > are documented we can hopefully replace this hack with a better patch.
>>
>> Could you please provide a bit more details in the commit message?
>> What are the symptoms of the problem?
>
> Without the patch, u-boot on the BananaPi shows massive packet loss
> on every network activity.  The packet loss is so extreme that it is
> actually impossible to boot a kernel by tftp because u-boot gives up.
> The mainline kernel has (once booted) shown similar problems on the
> BananaPi.
>
>> How did you come to the idea to poke these bits?
>
> The linux 3.4 kernel from https://github.com/LeMaker/linux-bananapi
> (which is a patched linux-sunxi.org 3.4 kernel) does not show this
> problem, so we started looking into what is different there, and the
> relevant change that was found was setting these particular
> undocumented bits.

File at issue here asking for the documentation
https://github.com/allwinner-zh/documents

>
>> Does the GMAC driver in the linux kernel need a similar
>> fix/workaround?
>
> Not as far as I can see - once u-boot has set these two bits during
> system initialization, the mainline kernel works fine without
> any changes.
>
>> Also as mentioned in another e-mail
>> http://lists.denx.de/pipermail/u-boot/2014-September/190096.html
>> u-boot configures the "912MHz @1.4V" CPU clock frequency/voltage
>> setup for sun7i hardware. And according to the information from Tony
>> Zhang, this is supposed to be unreliable for the Banana Pi. So what
>> happens to this GMAC bug if you just increase the dcdc2 voltage in
>> u-boot (or reduce the CPU clock frequency)?
>
> I can test that if you could tell me what would have to be changed
> in u-boot to do that.
>
> Regards,
> Karsten
> --
> Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
> sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
> Werbung sowie der Markt- oder Meinungsforschung.
>
> --
> 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: [U-Boot] [linux-sunxi] Re: [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig

[Hans de Goede]

Hi,

On 09/28/2014 11:36 PM, Ian Campbell wrote:
> On Sun, 2014-09-28 at 20:10 +0200, Hans de Goede wrote:
>> On 09/28/2014 06:20 PM, Ian Campbell wrote:
>>> On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote:
> 
 Before you do that, note that I've just added 2 patches there, which I 
 would
 like to get into v2014.10. Specifically I'm hoping that I can get some
 positive testing feedback on the bananapi gmac patch I've send (off-list),
 and I believe we really should try to get the bananapi fix into v2014.10,
 and if we're going todo a pull-req for v2014.10, we might as well include
 the 2 patches I've just added to next. Do you agree ?
>>>
>>> You mean these two?
>>> sun7i: Add support for Olimex A20-OLinuXino-LIME2
>>> mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i
>>
>> Yes.
>>
>>> The latter seems like a feature to me, or at least the changelog doesn't
>>> give any rationale why it should go in now rather than waiting for the
>>> next merge window (i.e. why it's a bugfix, what the upside is to justify
>>> its inclusion now). How much testing has it had and what are the
>>> potential downsides?
>>
>> AFAIK the downside is that High Capacity cards will not work without it.
>>
>> Looking at the code if this bit is set, then for some commands
>> drivers/mmc/mmc.c or-s in OCR_HCS into the mmc cmdarg, so I guess you're
>> right that this may cause some undesirable side effects, so lets delay
>> this one.
> 
> OK.
> 
>>> WRT the new board (and new boards generally), I'm in two minds. On the
>>> one hand they are pretty low risk (can't regress anything else, at least
>>> not in this case), on the other we are 6 weeks past the close of the
>>> merge window and 2 from the release date, so we are pretty far along.
>>> Where do we draw the line?
>>
>> Normally I would not include new boards at this moment in the cycle, but
>> since we need to do a pull-req for the gmac anyways I thought it would
>> be nice to have it included, esp. since many distros only spin things
>> like sdcard boot images once, so if we do not include it now, many distros
>> will not get it for a significant amount of time.
> 
> There's always Just One More Board(tm) ;-)

Right, so lets just drop the board and I'll do a pull-req with only the
bananapi gmac fix, can I have your Reviewed-by for that one please?

>> Either way let me know how you want to proceed, if you think we should not
>> include this, then I'll send a pull-req with only the gmac fix.
> 
> As I say I'm in two minds. I'm not really sure what the u-boot norm is
> on this, I was hoping someone might chime in (although it's not been
> very long and the thread topic doesn't exactly scream for attention).
> Maybe run it by Albert/Tom and see how they feel about such things in
> general?
> 
> Where run it by might be two alternate PRs? Or a PR structured so the
> new board can trivially be dropped?
> 
>>> The gmac fix is a clear bug fix and once it is properly posted publicly
>>> I will ack and then I agree it should go in.
>>
>> I was hoping for Stephen to get around to testing it today, and then I wanted
>> to send it out with his Tested-by. I'll just go and send it as is for now.
> 
> s/Stephen/Karsten/?

Yes, my bad.

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

[Michal Suchanek]

On 29 September 2014 19:51, jonsm...@gmail.com  wrote:
> On Mon, Sep 29, 2014 at 4:06 AM, Thierry Reding
>  wrote:
>>
>> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> > Quoting Maxime Ripard (2014-09-02 02:25:08)
>> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > > > > > I would think the memory should still be reserved anyway to make 
>> > > > > > sure
>> > > > > > nothing else is writing over it. And it's in the device tree anyway
>> > > > > > because the driver needs to know where to put framebuffer content. 
>> > > > > > So
>> > > > > > the point I was trying to make is that we can't treat the memory 
>> > > > > > in the
>> > > > > > same way as clocks because it needs to be explicitly managed. 
>> > > > > > Whereas
>> > > > > > clocks don't. The driver is simply too generic to know what to do 
>> > > > > > with
>> > > > > > the clocks.
>> > > > >
>> > > > > You agreed on the fact that the only thing we need to do with the
>> > > > > clocks is claim them. Really, I don't find what's complicated there
>> > > > > (or not generic).
>> > > >
>> > > > That's not what I agreed on. What I said is that the only thing we need
>> > > > to do with the clocks is nothing. They are already in the state that
>> > > > they need to be.
>> > >
>> > > Claim was probably a poor choice of words, but still. We have to keep
>> > > the clock running, and both the solution you've been giving and this
>> > > patch do so in a generic way.
>> > >
>> > > > > > It doesn't know what frequency they should be running at
>> > > > >
>> > > > > We don't care about that. Just like we don't care about which
>> > > > > frequency is the memory bus running at. It will just run at whatever
>> > > > > frequency is appropriate.
>> > > >
>> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> > > > already configured the clocks to run at the correct frequencies, and it
>> > > > has made sure that they are enabled.
>> > > >
>> > > > > > or what they're used for
>> > > > >
>> > > > > And we don't care about that either. You're not interested in what
>> > > > > output the framebuffer is setup to use, which is pretty much the same
>> > > > > here, this is the same thing here.
>> > > >
>> > > > That's precisely what I've been saying. The only thing that simplefb
>> > > > cares about is the memory it should be using and the format of the
>> > > > pixels (and how many of them) it writes into that memory. Everything
>> > > > else is assumed to have been set up.
>> > > >
>> > > > Including clocks.
>> > >
>> > > We're really discussing in circles here.
>> > >
>> > > Mike?
>> > >
>> >
>> > -EHIGHLATENCYRESPONSE
>> >
>> > I forgot about this thread. Sorry.
>> >
>> > In an attempt to provide the least helpful answer possible, I will stay
>> > clear of all of the stuff relating to "how simple should simplefb be"
>> > and the related reserved memory discussion.
>> >
>> > A few times in this thread it is stated that we can't prevent unused
>> > clocks from being disabled. That is only partially true.
>> >
>> > The clock framework DOES provide a flag to prevent UNUSED clocks from
>> > being disabled at late_initcall-time by a clock "garbage collector"
>> > mechanism. Maxime and others familiar with the clock framework are aware
>> > of this.
>> >
>> > What the framework doesn't do is to allow for a magic flag in DT, in
>> > platform_data or elsewhere that says, "don't let me get turned off until
>> > the right driver claims me". That would be an external or alternative
>> > method for preventing a clock from being disabled. We have a method for
>> > preventing clocks from being disabled. It is as follows:
>> >
>> > struct clk *my_clk = clk_get(...);
>> > clk_prepare_enable(my_clk);
>> >
>> > That is how it should be done. Period.
>> >
>> > With that said I think that Luc's approach is very sensible. I'm not
>> > sure what purpose in the universe DT is supposed to serve if not for
>> > _this_exact_case_. We have a nice abstracted driver, usable by many
>> > people. The hardware details of how it is hooked up at the board level
>> > can all be hidden behind stable DT bindings that everyone already uses.
>>
>> simplefb doesn't deal at all with hardware details. It simply uses what
>> firmware has set up, which is the only reason why it will work for many
>> people. What is passed in via its device tree node is the minimum amount
>> of information needed to draw something into the framebuffer. Also note
>> that the simplefb device tree node is not statically added to a DTS file
>> but needs to be dynamically generated by firmware at runtime.
>>
>> If we start extending the binding with board-level details we end up
>> duplicating the device tree node for the proper video device. Also note
>> that it won't stop at clocks. Other setups will require reg

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

[jonsm...@gmail.com]

On Mon, Sep 29, 2014 at 4:06 AM, Thierry Reding
 wrote:
>
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-02 02:25:08)
> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > > I would think the memory should still be reserved anyway to make 
> > > > > > sure
> > > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > > because the driver needs to know where to put framebuffer content. 
> > > > > > So
> > > > > > the point I was trying to make is that we can't treat the memory in 
> > > > > > the
> > > > > > same way as clocks because it needs to be explicitly managed. 
> > > > > > Whereas
> > > > > > clocks don't. The driver is simply too generic to know what to do 
> > > > > > with
> > > > > > the clocks.
> > > > >
> > > > > You agreed on the fact that the only thing we need to do with the
> > > > > clocks is claim them. Really, I don't find what's complicated there
> > > > > (or not generic).
> > > >
> > > > That's not what I agreed on. What I said is that the only thing we need
> > > > to do with the clocks is nothing. They are already in the state that
> > > > they need to be.
> > >
> > > Claim was probably a poor choice of words, but still. We have to keep
> > > the clock running, and both the solution you've been giving and this
> > > patch do so in a generic way.
> > >
> > > > > > It doesn't know what frequency they should be running at
> > > > >
> > > > > We don't care about that. Just like we don't care about which
> > > > > frequency is the memory bus running at. It will just run at whatever
> > > > > frequency is appropriate.
> > > >
> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > > already configured the clocks to run at the correct frequencies, and it
> > > > has made sure that they are enabled.
> > > >
> > > > > > or what they're used for
> > > > >
> > > > > And we don't care about that either. You're not interested in what
> > > > > output the framebuffer is setup to use, which is pretty much the same
> > > > > here, this is the same thing here.
> > > >
> > > > That's precisely what I've been saying. The only thing that simplefb
> > > > cares about is the memory it should be using and the format of the
> > > > pixels (and how many of them) it writes into that memory. Everything
> > > > else is assumed to have been set up.
> > > >
> > > > Including clocks.
> > >
> > > We're really discussing in circles here.
> > >
> > > Mike?
> > >
> >
> > -EHIGHLATENCYRESPONSE
> >
> > I forgot about this thread. Sorry.
> >
> > In an attempt to provide the least helpful answer possible, I will stay
> > clear of all of the stuff relating to "how simple should simplefb be"
> > and the related reserved memory discussion.
> >
> > A few times in this thread it is stated that we can't prevent unused
> > clocks from being disabled. That is only partially true.
> >
> > The clock framework DOES provide a flag to prevent UNUSED clocks from
> > being disabled at late_initcall-time by a clock "garbage collector"
> > mechanism. Maxime and others familiar with the clock framework are aware
> > of this.
> >
> > What the framework doesn't do is to allow for a magic flag in DT, in
> > platform_data or elsewhere that says, "don't let me get turned off until
> > the right driver claims me". That would be an external or alternative
> > method for preventing a clock from being disabled. We have a method for
> > preventing clocks from being disabled. It is as follows:
> >
> > struct clk *my_clk = clk_get(...);
> > clk_prepare_enable(my_clk);
> >
> > That is how it should be done. Period.
> >
> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.
>
> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be


This is the key point -- if a design requires duplicating information
in the device tree, the design is broken. The list of clocks is being
dupli

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

[jonsm...@gmail.com]

On Mon, Sep 29, 2014 at 4:06 AM, Thierry Reding 
wrote:

> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-02 02:25:08)
> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > > I would think the memory should still be reserved anyway to make
> sure
> > > > > > nothing else is writing over it. And it's in the device tree
> anyway
> > > > > > because the driver needs to know where to put framebuffer
> content. So
> > > > > > the point I was trying to make is that we can't treat the memory
> in the
> > > > > > same way as clocks because it needs to be explicitly managed.
> Whereas
> > > > > > clocks don't. The driver is simply too generic to know what to
> do with
> > > > > > the clocks.
> > > > >
> > > > > You agreed on the fact that the only thing we need to do with the
> > > > > clocks is claim them. Really, I don't find what's complicated there
> > > > > (or not generic).
> > > >
> > > > That's not what I agreed on. What I said is that the only thing we
> need
> > > > to do with the clocks is nothing. They are already in the state that
> > > > they need to be.
> > >
> > > Claim was probably a poor choice of words, but still. We have to keep
> > > the clock running, and both the solution you've been giving and this
> > > patch do so in a generic way.
> > >
> > > > > > It doesn't know what frequency they should be running at
> > > > >
> > > > > We don't care about that. Just like we don't care about which
> > > > > frequency is the memory bus running at. It will just run at
> whatever
> > > > > frequency is appropriate.
> > > >
> > > > Exactly. And you shouldn't have to care about them at all. Firmware
> has
> > > > already configured the clocks to run at the correct frequencies, and
> it
> > > > has made sure that they are enabled.
> > > >
> > > > > > or what they're used for
> > > > >
> > > > > And we don't care about that either. You're not interested in what
> > > > > output the framebuffer is setup to use, which is pretty much the
> same
> > > > > here, this is the same thing here.
> > > >
> > > > That's precisely what I've been saying. The only thing that simplefb
> > > > cares about is the memory it should be using and the format of the
> > > > pixels (and how many of them) it writes into that memory. Everything
> > > > else is assumed to have been set up.
> > > >
> > > > Including clocks.
> > >
> > > We're really discussing in circles here.
> > >
> > > Mike?
> > >
> >
> > -EHIGHLATENCYRESPONSE
> >
> > I forgot about this thread. Sorry.
> >
> > In an attempt to provide the least helpful answer possible, I will stay
> > clear of all of the stuff relating to "how simple should simplefb be"
> > and the related reserved memory discussion.
> >
> > A few times in this thread it is stated that we can't prevent unused
> > clocks from being disabled. That is only partially true.
> >
> > The clock framework DOES provide a flag to prevent UNUSED clocks from
> > being disabled at late_initcall-time by a clock "garbage collector"
> > mechanism. Maxime and others familiar with the clock framework are aware
> > of this.
> >
> > What the framework doesn't do is to allow for a magic flag in DT, in
> > platform_data or elsewhere that says, "don't let me get turned off until
> > the right driver claims me". That would be an external or alternative
> > method for preventing a clock from being disabled. We have a method for
> > preventing clocks from being disabled. It is as follows:
> >
> > struct clk *my_clk = clk_get(...);
> > clk_prepare_enable(my_clk);
> >
> > That is how it should be done. Period.
> >
> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.
>
> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
>

This is the key point -- if a design requires duplicating information in
the device tree, the design is broken. The list of clocks is being
duplicated, that is broken design.

Device trees

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

[Luc Verhaegen]

On Mon, Sep 29, 2014 at 06:28:14PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> > 
> > This is a fundamental issue that we are facing and I'm trying to come up
> > with a solution that is future-proof and will work for drivers other
> > than simplefb.
> > 
> > Just because we currently lack this functionality doesn't make it a hack
> > trying to add it.
> 
> Or maybe it's just showing that the trend to rely more and more on the
> firmware is a bad idea?
> 
> I really start to consider adding a sunxi-uboot-fb, that would just
> duplicate the source code of simplefb but also taking the
> clocks. Somehow, I feel like it will be easier (and definitely less of
> a hack than using the generic common clock API).

In the 2nd round of this discussion, i stated that another fb or even a 
drm driver altogether seemed to be the sensible way out of this mess.

I suggest drm_rescue.

> > Then instead of hacking existing drivers to work on your particular
> > platform you should start looking into hacking your platform drivers to
> > cope with the lack of a proper display driver. Or alternatively spend
> > the time getting a proper display driver merged.
> > 
> > Whether simplefb is used as primary framebuffer or just during only boot
> > until hand-off to a real driver, it still remains a stop-gap solution.
> 
> Then really, simplefb deserves a more appropriate name. Like
> uselessfb, tegrafb, DONOTUSEITYOUSTUPIDDEVfb or whatever makes it not
> look generic.

Very early on, now almost two months back, i used the word "denialfb".
rpifb is the real name of this thing though, but then the dt binding 
names would have to change and whatnot.

I don't get the resistance, at least not from a technical point of view. 
And i do not care enough to get properly involved in this pointless and 
endless discussion. drm_rescue it is.

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

[Maxime Ripard]

On Mon, Sep 29, 2014 at 03:54:00PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > > >> your clock to be shut down as a side effect of a later clk_disable
> > > > >> call from another driver.
> > > > 
> > > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > > preceding clk_enable()? There are patches being worked on that will
> > > > > enable per-user clocks and as I understand it they will specifically
> > > > > disallow drivers to disable the hardware clock if other drivers are
> > > > > still keeping them on via their own referenc.
> > > > 
> > > > Calling clk_disable() preceding clk_enable() is a bug.
> > > > 
> > > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > > its parents)
> > > > if the clock subsystem thinks there are no other users, which is what 
> > > > will
> > > > happen here.
> > > 
> > > Right. I'm not sure this is really applicable to this situation, though.
> > 
> > It's actually very easy to do. Have a driver that probes, enables its
> > clock, fails to probe for any reason, call clk_disable in its exit
> > path. If there's no other user at that time of this particular clock
> > tree, it will be shut down. Bam. You just lost your framebuffer.
> > 
> > Really, it's just that simple, and relying on the fact that some other
> > user of the same clock tree will always be their is beyond fragile.
> 
> Perhaps the meaning clk_ignore_unused should be revised, then. What you
> describe isn't at all what I'd expect from such an option. And it does
> not match the description in Documentation/kernel-parameters.txt either.

Well, it never says that it also prevent them from being disabled
later on. But it's true it's not very explicit.

> > > Either way, if there are other users of a clock then they will just as
> > > likely want to modify the rate at which point simplefb will break just
> > > as badly.
> > 
> > And this can be handled just as well. Register a clock notifier,
> > refuse any rate change, done. But of course, that would require having
> > a clock handle.
> > 
> > Now, how would *you* prevent such a change?
> 
> Like I said in the other thread. If you have two drivers that use the
> same clock but need different frequencies you've lost anyway.

Except that the driver that has the most logic (ie not simplefb) will
have a way to recover and deal with that. You prevented the clock rate
*and* your system can react, I guess you actually won.

But sure, you can still try to point new issues, get an obvious and
robust solution, and then discard the issue when the solution doesn't
go your way...

Maxime

-- 
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 29 September 2014 17:49, Thierry Reding  wrote:
> On Mon, Sep 29, 2014 at 05:04:32PM +0200, Michal Suchanek wrote:
>> On 29 September 2014 15:47, Thierry Reding  wrote:
>> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
>> >> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> > > > simplefb doesn't deal at all with hardware details. It simply uses 
>> >> > > > what
>> >> > > > firmware has set up, which is the only reason why it will work for 
>> >> > > > many
>> >> > > > people. What is passed in via its device tree node is the minimum 
>> >> > > > amount
>> >> > > > of information needed to draw something into the framebuffer. Also 
>> >> > > > note
>> >> > > > that the simplefb device tree node is not statically added to a DTS 
>> >> > > > file
>> >> > > > but needs to be dynamically generated by firmware at runtime.
>> >> > >
>> >> > > Which makes the whole even simpler, since the firmware already knows
>> >> > > all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> Didn't you just say that it was dynamically generated at runtime? So
>> >> we can just ignore the "text editor" case.
>> >
>> > Perhaps read the sentence again. I said "that we would *otherwise* be
>> > able to do much easier with a text editor.".
>> >
>> > My point remains that there shouldn't be a need to generate DTB content
>> > of this complexity at all.
>> >
>> >> > Why do you think what I proposed isn't going to work or be reliable?
>> >> > I don't see any arguments in the thread that would imply that.
>> >>
>> >> The fact that it broke in the first place?
>> >
>> > That's exactly the point. And it's going to break again and again as
>> > simplefb is extended with new things. Generally DT bindings should be
>> > backwards compatible. When extended they should provide a way to fall
>> > back to a reasonable default. There's simply no way you can do that
>> > with simplefb.
>> >
>> > What happened in the Snow example is that regulators that were
>> > previously on would all of a sudden be automatically disabled on boot
>> > because there was now a driver that registered them with a generic
>> > framework.
>>
>> So what? You get a driver for regulators and suddenly find that
>> nothing registered regulators because they were on all the time anyway
>> and everything breaks? What a surprise!
>
> I agree, this is not a surprise at all. But like I pointed out this is
> bound to happen again and again. So how about we learn from it and add
> the functionality needed to prevent it from happening?
>
>> > The same thing is going to happen with simplefb for your device. If you
>> > later realize that you need a regulator to keep the panel going, you'll
>> > have to add code to your firmware to populate the corresponding
>> > properties, otherwise the regulator will end up unused and will be
>> > automatically disabled. At the same time you're going to break upstream
>> > for all users of your old firmware because it doesn't add that property
>> > yet.
>>
>> Sure. And what can you do about that? It's not like the original Snow
>> firmware writes anything of use to the DT at all. So to run a
>> development kernel you need a development firmware. If you add new
>> features to the kernel that involve intefacing to the firmware you
>> need to update the firmware as well. Once support for Snow platform is
>> stable you can expect that users can use a stable release of firmware
>> indefinitely.
>
> Feel free to take that up with the DT ABI stability committee.

As pointed out you can also generate by hand a DT that exactly
describes what the preinstalled firmware sets up - so long as the
preinstalled firmware sets upa any usable framebuffer at all and
always sets up the same thing. If the preinstalled firmware can set up
the framebuffer in different ways and is not willing to communicate to
the kernel in what way it set up the framebuffer then it is unusable
with simplefb. That sucks but there is no way around that.

>> > Why not? Are you really expecting to keep running with simplefb forever?
>> > Nobody is going to seriously use an upstream kernel in any product with
>> > only simplefb as a framebuffer. I've said before that this is a hack to
>>
>> Why not? You can use shadowfb (software acceleration) with simplefb
>> all right. Shadowfb is hands down the fastest video acceleration we
>> have on anything but hardware that has _very_ slow CPU or that can run
>> Intel UXA drivers. With manufacturers adding more and more superfluous
>> cores to the CPUs shadowfb is actually not too stressing on the
>> system, either.
>>
>> On hardware like Allwinner A13 (si

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

[Maxime Ripard]

On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > > [...]
> > > > > simplefb doesn't deal at all with hardware details. It simply uses 
> > > > > what
> > > > > firmware has set up, which is the only reason why it will work for 
> > > > > many
> > > > > people. What is passed in via its device tree node is the minimum 
> > > > > amount
> > > > > of information needed to draw something into the framebuffer. Also 
> > > > > note
> > > > > that the simplefb device tree node is not statically added to a DTS 
> > > > > file
> > > > > but needs to be dynamically generated by firmware at runtime.
> > > > 
> > > > Which makes the whole even simpler, since the firmware already knows
> > > > all about which clocks it had to enable.
> > > 
> > > It makes things very complicated in the firmware because it now needs to
> > > be able to generate DTB content that we would otherwise be able to do
> > > much easier with a text editor.
> > 
> > Didn't you just say that it was dynamically generated at runtime? So
> > we can just ignore the "text editor" case.
> 
> Perhaps read the sentence again. I said "that we would *otherwise* be
> able to do much easier with a text editor.".
> 
> My point remains that there shouldn't be a need to generate DTB content
> of this complexity at all.
> 
> > > Why do you think what I proposed isn't going to work or be reliable?
> > > I don't see any arguments in the thread that would imply that.
> > 
> > The fact that it broke in the first place?
> 
> That's exactly the point. And it's going to break again and again as
> simplefb is extended with new things. Generally DT bindings should be
> backwards compatible. When extended they should provide a way to fall
> back to a reasonable default. There's simply no way you can do that
> with simplefb.

This one *is* backward compatible. It doesn't even change the simplefb
behaviour, compared to what it was doing before, if you don't have
this clocks property. What can be a more reasonable default that the
way it used to behave?

> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.
> 
> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.
>
> And the same will continue to happen for every new type of resource
> you're going to add.

Sure, we can add any resources we will need. Regulators, reset lines,
pm domains, allocated memory, but I'm not really sure this is what you
want, right?

And if you don't do it, you end up in situations where you have to
tell your users "disable the regulator driver in order for your
display to work".
 
> > > > > So how about instead of requiring resources to be explicitly claimed 
> > > > > we
> > > > > introduce something like the below patch? The intention being to give
> > > > > "firmware device" drivers a way of signalling to the clock framework
> > > > > that they need rely on clocks set up by firmware and when they no 
> > > > > longer
> > > > > need them. This implements essentially what Mark (CC'ing again on this
> > > > > subthread) suggested earlier in this thread. Basically, it will allow
> > > > > drivers to determine the time when unused clocks are really unused. It
> > > > > will of course only work when used correctly by drivers. For the case 
> > > > > of
> > > > > simplefb I'd expect its .probe() implementation to call the new
> > > > > clk_ignore_unused() function and once it has handed over control of 
> > > > > the
> > > > > display hardware to the real driver it can call clk_unignore_unused() 
> > > > > to
> > > > > signal that all unused clocks that it cares about have now been 
> > > > > claimed.
> > > > > This is "reference counted" and can therefore be used by more than a
> > > > > single driver if necessary. Similar functionality could be added for
> > > > > other resource subsystems as needed.
> > > > 
> > > > So, just to be clear, instead of doing a generic clk_get and
> > > > clk_prepare_enable, you're willing to do a just as much generic
> > > > clk_ignore_unused call?
> > > 
> > > Yes.
> > > 
> > > > How is that less generic?
> > > 
> > > It's more generic. That's the whole point.
> > > 
> > > The difference is that with the solution I proposed we don't have to
> >

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

[Mark Brown]

On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:

> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.

> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.

Not really thought this through fully yet but would having phandles to
the relevant devices do the job?  Kind of lines up with Grant's idea of
having dummy drivers.

> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.

We might want to do that in the future, though it's not always the case
that reset is the lowest power state.

> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

One thing that makes me a bit nervous about this approach in the context
of the regulator API is the frequency with which one finds shared
supplies.  I'm not sure if it's actually a big problem in practice but
it makes me worry a bit.  We could probably just do something like make
refcounting down to zero not actually disable anything for standard
regulators to deal with it which might be an idea anyway in the context
of this sort of dodge.


signature.asc
Description: Digital signature

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

[Mark Brown]

On Mon, Sep 29, 2014 at 03:47:15PM +0200, Thierry Reding wrote:

> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.

Not quite - there was also DT added for them.  With just the driver the
regulator API shouldn't have touched them, it'd just have exposed them
read only.

> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.

> And the same will continue to happen for every new type of resource
> you're going to add.

So long as we're ensuring that when we don't start supporting resources
without DT additions or at least require DT additions to actively manage
them (which can then include simplefb hookup) we should be fine.

> > > The difference is that with the solution I proposed we don't have to
> > > keep track of all the resources. We know that firmware has set them up
> > > and we know that a real driver will properly take them over at some
> > > point

> > You keep saying that... and you know that you can't make this
> > assumption.

> Why not? Are you really expecting to keep running with simplefb forever?
> Nobody is going to seriously use an upstream kernel in any product with
> only simplefb as a framebuffer. I've said before that this is a hack to
> get you working display. And that's all it is. If you want to do it
> properly go and write a DRM/KMS driver.

Well, for product probably not.  But in terms of the runtime of a kernel
I'd not be so sure - people do dogfood and we should be allowing that.
I've used unaccelerated displays with reasonable success for a large
part of my work in the past.


signature.asc
Description: Digital signature

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 05:04:32PM +0200, Michal Suchanek wrote:
> On 29 September 2014 15:47, Thierry Reding  wrote:
> > On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> >> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> >> > [...]
> >> > > > simplefb doesn't deal at all with hardware details. It simply uses 
> >> > > > what
> >> > > > firmware has set up, which is the only reason why it will work for 
> >> > > > many
> >> > > > people. What is passed in via its device tree node is the minimum 
> >> > > > amount
> >> > > > of information needed to draw something into the framebuffer. Also 
> >> > > > note
> >> > > > that the simplefb device tree node is not statically added to a DTS 
> >> > > > file
> >> > > > but needs to be dynamically generated by firmware at runtime.
> >> > >
> >> > > Which makes the whole even simpler, since the firmware already knows
> >> > > all about which clocks it had to enable.
> >> >
> >> > It makes things very complicated in the firmware because it now needs to
> >> > be able to generate DTB content that we would otherwise be able to do
> >> > much easier with a text editor.
> >>
> >> Didn't you just say that it was dynamically generated at runtime? So
> >> we can just ignore the "text editor" case.
> >
> > Perhaps read the sentence again. I said "that we would *otherwise* be
> > able to do much easier with a text editor.".
> >
> > My point remains that there shouldn't be a need to generate DTB content
> > of this complexity at all.
> >
> >> > Why do you think what I proposed isn't going to work or be reliable?
> >> > I don't see any arguments in the thread that would imply that.
> >>
> >> The fact that it broke in the first place?
> >
> > That's exactly the point. And it's going to break again and again as
> > simplefb is extended with new things. Generally DT bindings should be
> > backwards compatible. When extended they should provide a way to fall
> > back to a reasonable default. There's simply no way you can do that
> > with simplefb.
> >
> > What happened in the Snow example is that regulators that were
> > previously on would all of a sudden be automatically disabled on boot
> > because there was now a driver that registered them with a generic
> > framework.
> 
> So what? You get a driver for regulators and suddenly find that
> nothing registered regulators because they were on all the time anyway
> and everything breaks? What a surprise!

I agree, this is not a surprise at all. But like I pointed out this is
bound to happen again and again. So how about we learn from it and add
the functionality needed to prevent it from happening?

> > The same thing is going to happen with simplefb for your device. If you
> > later realize that you need a regulator to keep the panel going, you'll
> > have to add code to your firmware to populate the corresponding
> > properties, otherwise the regulator will end up unused and will be
> > automatically disabled. At the same time you're going to break upstream
> > for all users of your old firmware because it doesn't add that property
> > yet.
> 
> Sure. And what can you do about that? It's not like the original Snow
> firmware writes anything of use to the DT at all. So to run a
> development kernel you need a development firmware. If you add new
> features to the kernel that involve intefacing to the firmware you
> need to update the firmware as well. Once support for Snow platform is
> stable you can expect that users can use a stable release of firmware
> indefinitely.

Feel free to take that up with the DT ABI stability committee.

> > And the same will continue to happen for every new type of resource
> > you're going to add.
> 
> The like 5 resource types, yes. Some of which may not even apply to simplefb.

Today it's 5, tomorrow 6, next year, who knows.

> >> > > > So how about instead of requiring resources to be explicitly claimed 
> >> > > > we
> >> > > > introduce something like the below patch? The intention being to give
> >> > > > "firmware device" drivers a way of signalling to the clock framework
> >> > > > that they need rely on clocks set up by firmware and when they no 
> >> > > > longer
> >> > > > need them. This implements essentially what Mark (CC'ing again on 
> >> > > > this
> >> > > > subthread) suggested earlier in this thread. Basically, it will allow
> >> > > > drivers to determine the time when unused clocks are really unused. 
> >> > > > It
> >> > > > will of course only work when used correctly by drivers. For the 
> >> > > > case of
> >> > > > simplefb I'd expect its .probe() implementation to call the new
> >> > > > clk_ignore_unused() function and once it has handed over control of 
> >> > > > the
> >> > > > display hardware to the real driver it can call 
> >> > > > clk_unignore_unused() to
> >> > > > signal that all unused

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

[Michal Suchanek]

On 29 September 2014 17:19, Thierry Reding  wrote:
> On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
>> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>> >>  wrote:
>> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> >> > [...]
>> >> >> > simplefb doesn't deal at all with hardware details. It simply uses 
>> >> >> > what
>> >> >> > firmware has set up, which is the only reason why it will work for 
>> >> >> > many
>> >> >> > people. What is passed in via its device tree node is the minimum 
>> >> >> > amount
>> >> >> > of information needed to draw something into the framebuffer. Also 
>> >> >> > note
>> >> >> > that the simplefb device tree node is not statically added to a DTS 
>> >> >> > file
>> >> >> > but needs to be dynamically generated by firmware at runtime.
>> >> >>
>> >> >> Which makes the whole even simpler, since the firmware already knows
>> >> >> all about which clocks it had to enable.
>> >> >
>> >> > It makes things very complicated in the firmware because it now needs to
>> >> > be able to generate DTB content that we would otherwise be able to do
>> >> > much easier with a text editor.
>> >>
>> >> As far as the kernel is concerned, this is a solved problem.
>> >
>> > It's not completely solved. There's still the issue of no generic way to
>> > specify regulators like you can do for clocks, resets or power domains.
>> > But the kernel isn't the real issue here. The issue is the firmware that
>> > now has to go out of its way not only to initialize display hardware but
>> > also create device tree content just to make Linux not turn everything
>> > off.
>>
>> My point is that the firmware is going to be doing complicated stuff
>> already, adding and using some helpers to configure a device tree node
>> is relatively simple in comparison to dealing with the actual
>> hardware. It wouldn't surprise me if u-boot, for example, ended up
>> with a set of functions to handle this exact case as more graphics
>> hardware gets brought up.
>
> Not all firmware is based on U-Boot. Essentially whatever binding
> changes we make will need to be implemented in all firmware. And the
> complexity isn't so much about writing the actual DT data, but more
> about figuring out which data to write. Every firmware image needs to
> know exactly which clocks and other resources to transcribe for a given
> board. It'll essentially need to contain some sort of "driver" for each
> device that parses a DTB, correlates the data to what it knows of the
> device internals and write a subset of that data back into the DTB in a
> slightly different format. That's just whacky.
>
> DT was meant to simplify things.

The firmware only needs to implement DT parsing and writing if it
wants to communicate the configuration it set up to the kernel. If you
do not have control over the firmware or do not want to write support
for the firmware to generate the DT you can produce a fixed
configuration DT and have the firmware load that with the kernel. It
is fully backwards compatible with dumb firmware that does not support
DT modification during boot. You will just need a different DT for
slightly different devices (eg. tablets with different display) or
different configurations of same device (eg. different displays
connected to the HDMI port of your devboard).

>> I'm sure that as hardware diversifies, the other subsystems will grow
>> in similar directions and eventually be dealt with using similarly
>> generic code.
>
> For regulators this already works very differently. As opposed to the
> clocks/clock-names type of binding it uses one where the consumer name
> of the regulator comes from the prefix of a -supply property. That is
> you'd get something like this:
>
> foo-supply = <®1>;
> bar-supply = <®2>;
>
> And since you don't have enough information in the kernel simplefb
> driver to attach any meaning to these, the best you can do would be
> iterating over a range and have:
>
> 0-supply = <®0>;
> 1-supply = <®1>;
> ...
> n-supply = <®2>;
>
> This is made more difficult by the fact that these regulators may be
> required by components not immediately related to the display engine.
> They could be for an attached panel, a video bridge or the +5V pin on
> the HDMI connector.

So you are saying that listing the properties of the simplefb node and
filtering foo-supply and bar-supply out of that is too difficult?

I hope kernel development did not get this dumb.

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

[Thierry Reding]

On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
>  wrote:
> > On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
> >> Hi Thierry,
> >
> > If you address people directly please make sure they are in the To:
> > line. Or at least Cc.
> 
> Sorry about that, the mailing list I received this through (Google
> Groups based) generally strips to: and CC: lines, so my mail client
> (Gmail) doesn't do it automatically. I'm still getting used to it.

Yeah, I wish mailing lists would stop doing that.

> >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
> >>  wrote:
> >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> >> > [...]
> >> >> > simplefb doesn't deal at all with hardware details. It simply uses 
> >> >> > what
> >> >> > firmware has set up, which is the only reason why it will work for 
> >> >> > many
> >> >> > people. What is passed in via its device tree node is the minimum 
> >> >> > amount
> >> >> > of information needed to draw something into the framebuffer. Also 
> >> >> > note
> >> >> > that the simplefb device tree node is not statically added to a DTS 
> >> >> > file
> >> >> > but needs to be dynamically generated by firmware at runtime.
> >> >>
> >> >> Which makes the whole even simpler, since the firmware already knows
> >> >> all about which clocks it had to enable.
> >> >
> >> > It makes things very complicated in the firmware because it now needs to
> >> > be able to generate DTB content that we would otherwise be able to do
> >> > much easier with a text editor.
> >>
> >> As far as the kernel is concerned, this is a solved problem.
> >
> > It's not completely solved. There's still the issue of no generic way to
> > specify regulators like you can do for clocks, resets or power domains.
> > But the kernel isn't the real issue here. The issue is the firmware that
> > now has to go out of its way not only to initialize display hardware but
> > also create device tree content just to make Linux not turn everything
> > off.
> 
> My point is that the firmware is going to be doing complicated stuff
> already, adding and using some helpers to configure a device tree node
> is relatively simple in comparison to dealing with the actual
> hardware. It wouldn't surprise me if u-boot, for example, ended up
> with a set of functions to handle this exact case as more graphics
> hardware gets brought up.

Not all firmware is based on U-Boot. Essentially whatever binding
changes we make will need to be implemented in all firmware. And the
complexity isn't so much about writing the actual DT data, but more
about figuring out which data to write. Every firmware image needs to
know exactly which clocks and other resources to transcribe for a given
board. It'll essentially need to contain some sort of "driver" for each
device that parses a DTB, correlates the data to what it knows of the
device internals and write a subset of that data back into the DTB in a
slightly different format. That's just whacky.

DT was meant to simplify things.

> >> Firmware is going to be doing some dark magic to set up the hardware
> >> to be a dumb frame buffer and some other stuff to add the simplefb
> >> device node - so by this point, adding the clocks (or whatever)
> >> required by the hardware should be fairly uncomplicated - the firmware
> >> already knows the hardware intimately. As for the actual device tree
> >> manipulations, U-boot (or whatever) will probably just grow some
> >> helper functions to make this simple.
> >
> > Have you looked at the code needed to do this? It's not at all trivial.
> > And the point is really that all this information is there already, so
> > we're completely duplicating this into a dynamically created device tree
> > node and for what reason? Only to have one driver request all these
> > resources and have them forcefully released a few seconds later.
> >
> >> Alternatively, it could simply add the relevant data to an existing
> >> device node and munge it's compatible property so simplefb picks it
> >> up.
> >
> > Yes, I think that'd be a much better solution. Of course it's going to
> > be very difficult to make that work with a generic driver because now
> > that generic driver needs to parse the DT binding for any number of
> > "compatible" devices.
> 
> Not necessarily.
> 
> The patch that started this discussion can work with any number of
> clocks specified in a "clocks" property. Therefore all that needs to
> happen is that the final hardware binding specifies it's clocks that
> way.

Are you suggesting that we should be modeling the hardware specific
binding to match what the simplefb binding does?

> I'm sure that as hardware diversifies, the other subsystems will grow
> in similar directions and eventually be dealt with using similarly
> generic code.

For regulators this already works very differe

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

[Michal Suchanek]

On 29 September 2014 15:47, Thierry Reding  wrote:
> On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
>> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
>> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> > [...]
>> > > > simplefb doesn't deal at all with hardware details. It simply uses what
>> > > > firmware has set up, which is the only reason why it will work for many
>> > > > people. What is passed in via its device tree node is the minimum 
>> > > > amount
>> > > > of information needed to draw something into the framebuffer. Also note
>> > > > that the simplefb device tree node is not statically added to a DTS 
>> > > > file
>> > > > but needs to be dynamically generated by firmware at runtime.
>> > >
>> > > Which makes the whole even simpler, since the firmware already knows
>> > > all about which clocks it had to enable.
>> >
>> > It makes things very complicated in the firmware because it now needs to
>> > be able to generate DTB content that we would otherwise be able to do
>> > much easier with a text editor.
>>
>> Didn't you just say that it was dynamically generated at runtime? So
>> we can just ignore the "text editor" case.
>
> Perhaps read the sentence again. I said "that we would *otherwise* be
> able to do much easier with a text editor.".
>
> My point remains that there shouldn't be a need to generate DTB content
> of this complexity at all.
>
>> > Why do you think what I proposed isn't going to work or be reliable?
>> > I don't see any arguments in the thread that would imply that.
>>
>> The fact that it broke in the first place?
>
> That's exactly the point. And it's going to break again and again as
> simplefb is extended with new things. Generally DT bindings should be
> backwards compatible. When extended they should provide a way to fall
> back to a reasonable default. There's simply no way you can do that
> with simplefb.
>
> What happened in the Snow example is that regulators that were
> previously on would all of a sudden be automatically disabled on boot
> because there was now a driver that registered them with a generic
> framework.

So what? You get a driver for regulators and suddenly find that
nothing registered regulators because they were on all the time anyway
and everything breaks? What a surprise!

>
> The same thing is going to happen with simplefb for your device. If you
> later realize that you need a regulator to keep the panel going, you'll
> have to add code to your firmware to populate the corresponding
> properties, otherwise the regulator will end up unused and will be
> automatically disabled. At the same time you're going to break upstream
> for all users of your old firmware because it doesn't add that property
> yet.

Sure. And what can you do about that? It's not like the original Snow
firmware writes anything of use to the DT at all. So to run a
development kernel you need a development firmware. If you add new
features to the kernel that involve intefacing to the firmware you
need to update the firmware as well. Once support for Snow platform is
stable you can expect that users can use a stable release of firmware
indefinitely.

>
> And the same will continue to happen for every new type of resource
> you're going to add.

The like 5 resource types, yes. Some of which may not even apply to simplefb.

>
>> > > > So how about instead of requiring resources to be explicitly claimed we
>> > > > introduce something like the below patch? The intention being to give
>> > > > "firmware device" drivers a way of signalling to the clock framework
>> > > > that they need rely on clocks set up by firmware and when they no 
>> > > > longer
>> > > > need them. This implements essentially what Mark (CC'ing again on this
>> > > > subthread) suggested earlier in this thread. Basically, it will allow
>> > > > drivers to determine the time when unused clocks are really unused. It
>> > > > will of course only work when used correctly by drivers. For the case 
>> > > > of
>> > > > simplefb I'd expect its .probe() implementation to call the new
>> > > > clk_ignore_unused() function and once it has handed over control of the
>> > > > display hardware to the real driver it can call clk_unignore_unused() 
>> > > > to
>> > > > signal that all unused clocks that it cares about have now been 
>> > > > claimed.
>> > > > This is "reference counted" and can therefore be used by more than a
>> > > > single driver if necessary. Similar functionality could be added for
>> > > > other resource subsystems as needed.
>> > >
>> > > So, just to be clear, instead of doing a generic clk_get and
>> > > clk_prepare_enable, you're willing to do a just as much generic
>> > > clk_ignore_unused call?
>> >
>> > Yes.
>> >
>> > > How is that less generic?
>> >
>> > It's more generic. That's the whole point.
>> >
>> > The difference is that with the solution I proposed we don't have 

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

[Julian Calaby]

Hi Thierry,

On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding
 wrote:
> On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
>> Hi Thierry,
>
> If you address people directly please make sure they are in the To:
> line. Or at least Cc.

Sorry about that, the mailing list I received this through (Google
Groups based) generally strips to: and CC: lines, so my mail client
(Gmail) doesn't do it automatically. I'm still getting used to it.

>> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>>  wrote:
>> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
>> > [...]
>> >> > simplefb doesn't deal at all with hardware details. It simply uses what
>> >> > firmware has set up, which is the only reason why it will work for many
>> >> > people. What is passed in via its device tree node is the minimum amount
>> >> > of information needed to draw something into the framebuffer. Also note
>> >> > that the simplefb device tree node is not statically added to a DTS file
>> >> > but needs to be dynamically generated by firmware at runtime.
>> >>
>> >> Which makes the whole even simpler, since the firmware already knows
>> >> all about which clocks it had to enable.
>> >
>> > It makes things very complicated in the firmware because it now needs to
>> > be able to generate DTB content that we would otherwise be able to do
>> > much easier with a text editor.
>>
>> As far as the kernel is concerned, this is a solved problem.
>
> It's not completely solved. There's still the issue of no generic way to
> specify regulators like you can do for clocks, resets or power domains.
> But the kernel isn't the real issue here. The issue is the firmware that
> now has to go out of its way not only to initialize display hardware but
> also create device tree content just to make Linux not turn everything
> off.

My point is that the firmware is going to be doing complicated stuff
already, adding and using some helpers to configure a device tree node
is relatively simple in comparison to dealing with the actual
hardware. It wouldn't surprise me if u-boot, for example, ended up
with a set of functions to handle this exact case as more graphics
hardware gets brought up.

>> Firmware is going to be doing some dark magic to set up the hardware
>> to be a dumb frame buffer and some other stuff to add the simplefb
>> device node - so by this point, adding the clocks (or whatever)
>> required by the hardware should be fairly uncomplicated - the firmware
>> already knows the hardware intimately. As for the actual device tree
>> manipulations, U-boot (or whatever) will probably just grow some
>> helper functions to make this simple.
>
> Have you looked at the code needed to do this? It's not at all trivial.
> And the point is really that all this information is there already, so
> we're completely duplicating this into a dynamically created device tree
> node and for what reason? Only to have one driver request all these
> resources and have them forcefully released a few seconds later.
>
>> Alternatively, it could simply add the relevant data to an existing
>> device node and munge it's compatible property so simplefb picks it
>> up.
>
> Yes, I think that'd be a much better solution. Of course it's going to
> be very difficult to make that work with a generic driver because now
> that generic driver needs to parse the DT binding for any number of
> "compatible" devices.

Not necessarily.

The patch that started this discussion can work with any number of
clocks specified in a "clocks" property. Therefore all that needs to
happen is that the final hardware binding specifies it's clocks that
way. This is how, for example, the ahci_platform driver's clock code
works.

I'm sure that as hardware diversifies, the other subsystems will grow
in similar directions and eventually be dealt with using similarly
generic code.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

-- 
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: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s

[Simos Xenitellis]

On Mon, Sep 29, 2014 at 3:35 PM, jonsm...@gmail.com 
wrote:

>
>
> On Mon, Sep 29, 2014 at 5:46 AM, ke...@allwinnertech.com <
> ke...@allwinnertech.com> wrote:
>
>>  Hi All,
>>
>>  I have put the documents on github, and the url is
>> https://github.com/allwinner-zh/documents.git
>> Thanks Simos, Henrik and Luc's suggestion. And other documents will be
>> upated to here when released.
>>
>
>
> This also gives us a place to track documentation issues.
>
> I just created two - S/PDIF and TV decoder.
> https://github.com/allwinner-zh/documents/issues
>
> I believe there are a bunch more smaller issues - like bits in the codec
> and gmac controllers that are missing doc. Everyone can add issues for
> these as we find them.
>
> Allwinner should watch the issue list, I believe you will get mail when on
> is created. Then as the various items get documented, upload a new manual
> revision and close the issue. This lets the community help find
> documentation problems instead of Allwinner having to do everything.
>
> This git hub account is also an excellent place to put copies of the
> various SDKs. It is better if you don't put them up as giant 6GB tarballs.
> Push them up as trees of files. Doing it that way lets people look at
> individual files without having to download 6GB.
>

There is a soft limit for 1GB per repository at github. That refers to the
size of the .git/ directory in a repository
and not the "checked out" files. The Linux kernel is about 100MB of such
space. So there is enough space.
A single file on github can be up to 100MB, thus no big tarballs/zips can
fit there.
More at https://help.github.com/articles/what-is-my-disk-quota

As Jon mentioned, please check the Issues page on github for the
documentation, and once an issue is dealt with, you can click to close
them.
More at https://guides.github.com/features/issues/

Thanks for adding the files on github and we are looking forward to seeing
the rest of the repositories at https://github.com/allwinner-zh being
populated.

Simos


>
>>
>>
>>  --
>>  Best Regards,
>> kevin.z.m
>>
>>
>>
>>  *From:* HenrikNordström 
>> *Date:* 2014-09-29 08:46
>> *To:* linux-sunxi@googlegroups.com
>> *CC:* sh...@allwinnertech.com; Meng Zhang 
>> *Subject:* Re: [linux-sunxi] Allwinner documentation (hardware
>> datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
>>   sön 2014-09-28 klockan 02:18 +0200 skrev Luc Verhaegen:
>>
>> > Why didn't someone from Allwinner send these documents in him/herself?
>>
>> The current person discussion the matter with Allwiner was Simos, who is
>> part of the linux-sunxi community. Allwinner sent current versions of
>> the documents to Simos for distribution in the community. What is wrong?
>>
>> Mailing the full set of documents as attachments directly to the
>> mailinglist is not appropriate. And for some strange and unknown reason
>> Allwinner do not appear to have a public document archive for this kind
>> of documents themselves, and seems to only distribute them via email to
>> their customers when requested.
>>
>> The real question is why AW do not make the documents available in
>> public themselves, and likewise why they do not have a public git
>> repository for SDK sources etc (github or elsewhere).
>>
>> Regards
>> Henrik
>>
>>
>> NOTICE: This e-mail and any included attachments are intended only for
>> the sole use of named and intended recipient (s) only. If you are the named
>> and intended recipient, please note that the information contained in this
>> email and its embedded files are confidential and privileged. If you are
>> neither the intended nor named recipient, you are hereby notified that any
>> unauthorized review, use, disclosure, dissemination, distribution, or
>> copying of this communication, or any of its contents, is strictly
>> prohibited. Please reply to the sender and destroy the original message and
>> all your records of this message (whether electronic or otherwise).
>> Furthermore, you should not disclose to any other person, use, copy or
>> disseminate the contents of this e-mail and/or the documents accompanying
>> it.
>>
>> --
>> 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.
>

-- 
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+unsubs

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 01:32:44PM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 12:44 PM, Thierry Reding
>  wrote:
> >> >> You know that you are going to call that for regulator, reset, power
> >> >> domains, just as you would have needed to with the proper API, unless
> >> >> that with this kind of solution, you would have to modify *every*
> >> >> framework that might interact with any resource involved in getting
> >> >> simplefb running?
> >> >
> >> > We have to add handling for every kind of resource either way. Also if
> >> > this evolves into a common pattern we can easily wrap it up in a single
> >> > function call.
> >>
> >> disable_all_power_management(), as this is not limited to clocks.
> >
> > Right. But it isn't all power management either. It just shouldn't turn
> > everything unused off. Clocks, regulators, power domains and so on which
> > are used can very well be power managed.
> 
> No they can't, as the clock/regulator/PM domain core cannot know if any
> of the used ones are also used by a shim driver like simplefb.
> Clocks and regulators may be shared. PM domains can contain multiple
> hardware blocks. Without more knowledge, the only safe thing is not
> disabling anything.

Indeed. That's a shame. In the most common case that probably won't
matter all that much, given that the real driver can be expected to load
within a reasonable amount of time.

> >> >> Plus, speaking more specifically about the clocks, that won't prevent
> >> >> your clock to be shut down as a side effect of a later clk_disable
> >> >> call from another driver.
> >>
> >> > Furthermore isn't it a bug for a driver to call clk_disable() before a
> >> > preceding clk_enable()? There are patches being worked on that will
> >> > enable per-user clocks and as I understand it they will specifically
> >> > disallow drivers to disable the hardware clock if other drivers are
> >> > still keeping them on via their own referenc.
> >>
> >> Calling clk_disable() preceding clk_enable() is a bug.
> >>
> >> Calling clk_disable() after clk_enable() will disable the clock (and
> >> its parents)
> >> if the clock subsystem thinks there are no other users, which is what will
> >> happen here.
> >
> > Right. I'm not sure this is really applicable to this situation, though.
> 
> Yes it is: if all users of a clock/regulator/PM domain are gone, it will
> be disabled. Bad luck for simplefb still needing them.

Hmm... if all users are gone, then aren't the resources unused again and
should therefore be ignored?

Thierry


pgpIoQc_lLPua.pgp
Description: PGP signature

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > > >> Plus, speaking more specifically about the clocks, that won't prevent
> > > >> your clock to be shut down as a side effect of a later clk_disable
> > > >> call from another driver.
> > > 
> > > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > > preceding clk_enable()? There are patches being worked on that will
> > > > enable per-user clocks and as I understand it they will specifically
> > > > disallow drivers to disable the hardware clock if other drivers are
> > > > still keeping them on via their own referenc.
> > > 
> > > Calling clk_disable() preceding clk_enable() is a bug.
> > > 
> > > Calling clk_disable() after clk_enable() will disable the clock (and
> > > its parents)
> > > if the clock subsystem thinks there are no other users, which is what will
> > > happen here.
> > 
> > Right. I'm not sure this is really applicable to this situation, though.
> 
> It's actually very easy to do. Have a driver that probes, enables its
> clock, fails to probe for any reason, call clk_disable in its exit
> path. If there's no other user at that time of this particular clock
> tree, it will be shut down. Bam. You just lost your framebuffer.
> 
> Really, it's just that simple, and relying on the fact that some other
> user of the same clock tree will always be their is beyond fragile.

Perhaps the meaning clk_ignore_unused should be revised, then. What you
describe isn't at all what I'd expect from such an option. And it does
not match the description in Documentation/kernel-parameters.txt either.

> > Either way, if there are other users of a clock then they will just as
> > likely want to modify the rate at which point simplefb will break just
> > as badly.
> 
> And this can be handled just as well. Register a clock notifier,
> refuse any rate change, done. But of course, that would require having
> a clock handle.
> 
> Now, how would *you* prevent such a change?

Like I said in the other thread. If you have two drivers that use the
same clock but need different frequencies you've lost anyway.

Thierry


pgpKPih4ESVw2.pgp
Description: PGP signature

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 01:46:43PM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > [...]
> > > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > > firmware has set up, which is the only reason why it will work for many
> > > > people. What is passed in via its device tree node is the minimum amount
> > > > of information needed to draw something into the framebuffer. Also note
> > > > that the simplefb device tree node is not statically added to a DTS file
> > > > but needs to be dynamically generated by firmware at runtime.
> > > 
> > > Which makes the whole even simpler, since the firmware already knows
> > > all about which clocks it had to enable.
> > 
> > It makes things very complicated in the firmware because it now needs to
> > be able to generate DTB content that we would otherwise be able to do
> > much easier with a text editor.
> 
> Didn't you just say that it was dynamically generated at runtime? So
> we can just ignore the "text editor" case.

Perhaps read the sentence again. I said "that we would *otherwise* be
able to do much easier with a text editor.".

My point remains that there shouldn't be a need to generate DTB content
of this complexity at all.

> > Why do you think what I proposed isn't going to work or be reliable?
> > I don't see any arguments in the thread that would imply that.
> 
> The fact that it broke in the first place?

That's exactly the point. And it's going to break again and again as
simplefb is extended with new things. Generally DT bindings should be
backwards compatible. When extended they should provide a way to fall
back to a reasonable default. There's simply no way you can do that
with simplefb.

What happened in the Snow example is that regulators that were
previously on would all of a sudden be automatically disabled on boot
because there was now a driver that registered them with a generic
framework.

The same thing is going to happen with simplefb for your device. If you
later realize that you need a regulator to keep the panel going, you'll
have to add code to your firmware to populate the corresponding
properties, otherwise the regulator will end up unused and will be
automatically disabled. At the same time you're going to break upstream
for all users of your old firmware because it doesn't add that property
yet.

And the same will continue to happen for every new type of resource
you're going to add.

> > > > So how about instead of requiring resources to be explicitly claimed we
> > > > introduce something like the below patch? The intention being to give
> > > > "firmware device" drivers a way of signalling to the clock framework
> > > > that they need rely on clocks set up by firmware and when they no longer
> > > > need them. This implements essentially what Mark (CC'ing again on this
> > > > subthread) suggested earlier in this thread. Basically, it will allow
> > > > drivers to determine the time when unused clocks are really unused. It
> > > > will of course only work when used correctly by drivers. For the case of
> > > > simplefb I'd expect its .probe() implementation to call the new
> > > > clk_ignore_unused() function and once it has handed over control of the
> > > > display hardware to the real driver it can call clk_unignore_unused() to
> > > > signal that all unused clocks that it cares about have now been claimed.
> > > > This is "reference counted" and can therefore be used by more than a
> > > > single driver if necessary. Similar functionality could be added for
> > > > other resource subsystems as needed.
> > > 
> > > So, just to be clear, instead of doing a generic clk_get and
> > > clk_prepare_enable, you're willing to do a just as much generic
> > > clk_ignore_unused call?
> > 
> > Yes.
> > 
> > > How is that less generic?
> > 
> > It's more generic. That's the whole point.
> > 
> > The difference is that with the solution I proposed we don't have to
> > keep track of all the resources. We know that firmware has set them up
> > and we know that a real driver will properly take them over at some
> > point
> 
> You keep saying that... and you know that you can't make this
> assumption.

Why not? Are you really expecting to keep running with simplefb forever?
Nobody is going to seriously use an upstream kernel in any product with
only simplefb as a framebuffer. I've said before that this is a hack to
get you working display. And that's all it is. If you want to do it
properly go and write a DRM/KMS driver.

> > > You know that you are going to call that for regulator, reset, power
> > > domains, just as you would have needed to with the proper API, unless
> > > that with this kind of solution, you would have to modify *every*
> > > framework that might interact with any resource involved in getting
> > > simplefb running

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:
> Hi Thierry,

If you address people directly please make sure they are in the To:
line. Or at least Cc.

> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
>  wrote:
> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> > [...]
> >> > simplefb doesn't deal at all with hardware details. It simply uses what
> >> > firmware has set up, which is the only reason why it will work for many
> >> > people. What is passed in via its device tree node is the minimum amount
> >> > of information needed to draw something into the framebuffer. Also note
> >> > that the simplefb device tree node is not statically added to a DTS file
> >> > but needs to be dynamically generated by firmware at runtime.
> >>
> >> Which makes the whole even simpler, since the firmware already knows
> >> all about which clocks it had to enable.
> >
> > It makes things very complicated in the firmware because it now needs to
> > be able to generate DTB content that we would otherwise be able to do
> > much easier with a text editor.
> 
> As far as the kernel is concerned, this is a solved problem.

It's not completely solved. There's still the issue of no generic way to
specify regulators like you can do for clocks, resets or power domains.

But the kernel isn't the real issue here. The issue is the firmware that
now has to go out of its way not only to initialize display hardware but
also create device tree content just to make Linux not turn everything
off.

> Firmware is going to be doing some dark magic to set up the hardware
> to be a dumb frame buffer and some other stuff to add the simplefb
> device node - so by this point, adding the clocks (or whatever)
> required by the hardware should be fairly uncomplicated - the firmware
> already knows the hardware intimately. As for the actual device tree
> manipulations, U-boot (or whatever) will probably just grow some
> helper functions to make this simple.

Have you looked at the code needed to do this? It's not at all trivial.
And the point is really that all this information is there already, so
we're completely duplicating this into a dynamically created device tree
node and for what reason? Only to have one driver request all these
resources and have them forcefully released a few seconds later.

> Alternatively, it could simply add the relevant data to an existing
> device node and munge it's compatible property so simplefb picks it
> up.

Yes, I think that'd be a much better solution. Of course it's going to
be very difficult to make that work with a generic driver because now
that generic driver needs to parse the DT binding for any number of
"compatible" devices.

Thierry


pgpXeaVvCkSNz.pgp
Description: PGP signature

Re: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s

[jonsm...@gmail.com]

On Mon, Sep 29, 2014 at 5:46 AM, ke...@allwinnertech.com <
ke...@allwinnertech.com> wrote:

>  Hi All,
>
>  I have put the documents on github, and the url is
> https://github.com/allwinner-zh/documents.git
> Thanks Simos, Henrik and Luc's suggestion. And other documents will be
> upated to here when released.
>


This also gives us a place to track documentation issues.

I just created two - S/PDIF and TV decoder.
https://github.com/allwinner-zh/documents/issues

I believe there are a bunch more smaller issues - like bits in the codec
and gmac controllers that are missing doc. Everyone can add issues for
these as we find them.

Allwinner should watch the issue list, I believe you will get mail when on
is created. Then as the various items get documented, upload a new manual
revision and close the issue. This lets the community help find
documentation problems instead of Allwinner having to do everything.

This git hub account is also an excellent place to put copies of the
various SDKs. It is better if you don't put them up as giant 6GB tarballs.
Push them up as trees of files. Doing it that way lets people look at
individual files without having to download 6GB.


>
>
>  --
>  Best Regards,
> kevin.z.m
>
>
>
>  *From:* HenrikNordström 
> *Date:* 2014-09-29 08:46
> *To:* linux-sunxi@googlegroups.com
> *CC:* sh...@allwinnertech.com; Meng Zhang 
> *Subject:* Re: [linux-sunxi] Allwinner documentation (hardware datasheet,
> user manual) for A10, A10s, A13, A20, A31, A31s
>   sön 2014-09-28 klockan 02:18 +0200 skrev Luc Verhaegen:
>
> > Why didn't someone from Allwinner send these documents in him/herself?
>
> The current person discussion the matter with Allwiner was Simos, who is
> part of the linux-sunxi community. Allwinner sent current versions of
> the documents to Simos for distribution in the community. What is wrong?
>
> Mailing the full set of documents as attachments directly to the
> mailinglist is not appropriate. And for some strange and unknown reason
> Allwinner do not appear to have a public document archive for this kind
> of documents themselves, and seems to only distribute them via email to
> their customers when requested.
>
> The real question is why AW do not make the documents available in
> public themselves, and likewise why they do not have a public git
> repository for SDK sources etc (github or elsewhere).
>
> Regards
> Henrik
>
>
> NOTICE: This e-mail and any included attachments are intended only for the
> sole use of named and intended recipient (s) only. If you are the named and
> intended recipient, please note that the information contained in this
> email and its embedded files are confidential and privileged. If you are
> neither the intended nor named recipient, you are hereby notified that any
> unauthorized review, use, disclosure, dissemination, distribution, or
> copying of this communication, or any of its contents, is strictly
> prohibited. Please reply to the sender and destroy the original message and
> all your records of this message (whether electronic or otherwise).
> Furthermore, you should not disclose to any other person, use, copy or
> disseminate the contents of this e-mail and/or the documents accompanying
> it.
>
> --
> 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: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s

[Luc Verhaegen]

On Mon, Sep 29, 2014 at 05:46:35PM +0800, ke...@allwinnertech.com wrote:
> Hi All,
> 
> I have put the documents on github, and the url is 
> https://github.com/allwinner-zh/documents.git
> Thanks Simos, Henrik and Luc's suggestion. And other documents will be 
> upated to here when released.

Thanks!

Everyone who is interested who has a github account can set himself to 
watching and not miss a thing :)

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

[Maxime Ripard]

On Mon, Sep 29, 2014 at 12:18:08PM +0200, Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> > On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> [...]
> > > simplefb doesn't deal at all with hardware details. It simply uses what
> > > firmware has set up, which is the only reason why it will work for many
> > > people. What is passed in via its device tree node is the minimum amount
> > > of information needed to draw something into the framebuffer. Also note
> > > that the simplefb device tree node is not statically added to a DTS file
> > > but needs to be dynamically generated by firmware at runtime.
> > 
> > Which makes the whole even simpler, since the firmware already knows
> > all about which clocks it had to enable.
> 
> It makes things very complicated in the firmware because it now needs to
> be able to generate DTB content that we would otherwise be able to do
> much easier with a text editor.

Didn't you just say that it was dynamically generated at runtime? So
we can just ignore the "text editor" case.

> > > If we start extending the binding with board-level details we end up
> > > duplicating the device tree node for the proper video device. Also note
> > > that it won't stop at clocks. Other setups will require regulators to be
> > > listed in this device tree node as well so that they don't get disabled
> > > at late_initcall. And the regulator bindings don't provide a method to
> > > list an arbitrary number of clocks in a single property in the way that
> > > the clocks property works.
> > > 
> > > There may be also resets involved. Fortunately the reset framework is
> > > minimalistic enough not to care about asserting all unused resets at
> > > late_initcall. And other things like power domains may also need to be
> > > kept on.
> > > 
> > > Passing in clock information via the device tree already requires a non-
> > > trivial amount of code in the firmware. A similar amount of code would
> > > be necessary for each type of resource that needs to be kept enabled. In
> > > addition to the above some devices may also require resources that have
> > > no generic bindings. That just doesn't scale.
> > > 
> > > The only reasonable thing for simplefb to do is not deal with any kind
> > > of resource at all (except perhaps area that contains the framebuffer
> > > memory).
> > 
> > You should really read that thread:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
> > 
> > It's quite interesting, because you'll see that:
> > A) Your approach, even on the platform you're working on, doesn't
> >work. Or at least, isn't reliable.
> 
> What platform exactly do you think I'm working on?

My bad, I thought it was a tegra SoC in there. I should have read more
carefully obviously.

> Why do you think what I proposed isn't going to work or be reliable?
> I don't see any arguments in the thread that would imply that.

The fact that it broke in the first place?

> > B) Other maintainers, precisely like Mark, came to the same conclusion
> >than Mike.
> 
> Well, and others didn't.

We've been talking about both clocks and regulators up to now. I can
see Mike and Mark both suggesting to use the usual clocks and
regulators APIs, either in that thread or the one I pointed out.

> Also I think if you read that thread and look at my proposal it matches
> exactly what was discussed as one of the solutions at one point in the
> thread.

I've seen it, and replied to that already.

> > > So how about instead of requiring resources to be explicitly claimed we
> > > introduce something like the below patch? The intention being to give
> > > "firmware device" drivers a way of signalling to the clock framework
> > > that they need rely on clocks set up by firmware and when they no longer
> > > need them. This implements essentially what Mark (CC'ing again on this
> > > subthread) suggested earlier in this thread. Basically, it will allow
> > > drivers to determine the time when unused clocks are really unused. It
> > > will of course only work when used correctly by drivers. For the case of
> > > simplefb I'd expect its .probe() implementation to call the new
> > > clk_ignore_unused() function and once it has handed over control of the
> > > display hardware to the real driver it can call clk_unignore_unused() to
> > > signal that all unused clocks that it cares about have now been claimed.
> > > This is "reference counted" and can therefore be used by more than a
> > > single driver if necessary. Similar functionality could be added for
> > > other resource subsystems as needed.
> > 
> > So, just to be clear, instead of doing a generic clk_get and
> > clk_prepare_enable, you're willing to do a just as much generic
> > clk_ignore_unused call?
> 
> Yes.
> 
> > How is that less generic?
> 
> It's more generic. That's the whole point.
> 
> The difference is that with the solution I proposed we don't have to
> keep track of a

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

[Maxime Ripard]

On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote:
> > >> Plus, speaking more specifically about the clocks, that won't prevent
> > >> your clock to be shut down as a side effect of a later clk_disable
> > >> call from another driver.
> > 
> > > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > > preceding clk_enable()? There are patches being worked on that will
> > > enable per-user clocks and as I understand it they will specifically
> > > disallow drivers to disable the hardware clock if other drivers are
> > > still keeping them on via their own referenc.
> > 
> > Calling clk_disable() preceding clk_enable() is a bug.
> > 
> > Calling clk_disable() after clk_enable() will disable the clock (and
> > its parents)
> > if the clock subsystem thinks there are no other users, which is what will
> > happen here.
> 
> Right. I'm not sure this is really applicable to this situation, though.

It's actually very easy to do. Have a driver that probes, enables its
clock, fails to probe for any reason, call clk_disable in its exit
path. If there's no other user at that time of this particular clock
tree, it will be shut down. Bam. You just lost your framebuffer.

Really, it's just that simple, and relying on the fact that some other
user of the same clock tree will always be their is beyond fragile.

> Either way, if there are other users of a clock then they will just as
> likely want to modify the rate at which point simplefb will break just
> as badly.

And this can be handled just as well. Register a clock notifier,
refuse any rate change, done. But of course, that would require having
a clock handle.

Now, how would *you* prevent such a change?

Maxime

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

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 12:44 PM, Thierry Reding
 wrote:
>> >> You know that you are going to call that for regulator, reset, power
>> >> domains, just as you would have needed to with the proper API, unless
>> >> that with this kind of solution, you would have to modify *every*
>> >> framework that might interact with any resource involved in getting
>> >> simplefb running?
>> >
>> > We have to add handling for every kind of resource either way. Also if
>> > this evolves into a common pattern we can easily wrap it up in a single
>> > function call.
>>
>> disable_all_power_management(), as this is not limited to clocks.
>
> Right. But it isn't all power management either. It just shouldn't turn
> everything unused off. Clocks, regulators, power domains and so on which
> are used can very well be power managed.

No they can't, as the clock/regulator/PM domain core cannot know if any
of the used ones are also used by a shim driver like simplefb.
Clocks and regulators may be shared. PM domains can contain multiple
hardware blocks. Without more knowledge, the only safe thing is not
disabling anything.

>> >> Plus, speaking more specifically about the clocks, that won't prevent
>> >> your clock to be shut down as a side effect of a later clk_disable
>> >> call from another driver.
>>
>> > Furthermore isn't it a bug for a driver to call clk_disable() before a
>> > preceding clk_enable()? There are patches being worked on that will
>> > enable per-user clocks and as I understand it they will specifically
>> > disallow drivers to disable the hardware clock if other drivers are
>> > still keeping them on via their own referenc.
>>
>> Calling clk_disable() preceding clk_enable() is a bug.
>>
>> Calling clk_disable() after clk_enable() will disable the clock (and
>> its parents)
>> if the clock subsystem thinks there are no other users, which is what will
>> happen here.
>
> Right. I'm not sure this is really applicable to this situation, though.

Yes it is: if all users of a clock/regulator/PM domain are gone, it will
be disabled. Bad luck for simplefb still needing them.

> Either way, if there are other users of a clock then they will just as
> likely want to modify the rate at which point simplefb will break just
> as badly.

BTW, this can also happen for clocks that are properly used.
I guess the clock core code does some arbitration to handle such cases.

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.

[linux-sunxi] U-boot patch for Banana Pi

[hitxfd.t...@gmail.com]

Below is u-boot patch for Banana Pi.

In boards.cfg,  modified the STATUSLED to 248 to fit the user defined led on 
Banana Pi.
In boards.c, in original code the uboot will set the mac address only once when 
the board is first boot up. Then if we insert the SD card into another board, 
the mac address will not change, and remain the same mac address with the last  
board. So we need check the mac address every time, in case of we change the SD 
card into another board. 

>From 80eb21ef267321caed79927f914ec26a9a1d385b Mon Sep 17 00:00:00 2001
From: Tony Zhang 
Date: Sun, 28 Sep 2014 16:05:00 +0800
Subject: [PATCH] Fix the mac address can only set one time at the first time
the SD card is insert into Banana Pi. Change the status led
to the right PIN PH24.

Signed-off-by: Tony Zhang 
---
board/sunxi/board.c | 28 
boards.cfg | 4 ++--
2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 0f37d8d..a3ba4da 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -233,6 +233,34 @@ int misc_init_r(void)
eth_setenv_enetaddr("ethaddr", mac_addr);
}
}
+#ifdef CONFIG_BANANAPI
+ else {
+ unsigned char *p;
+ p = getenv("ethaddr");
+ uint32_t reg_val = readl(SUNXI_SID_BASE);
+
+ if (reg_val) {
+ uint8_t mac_addr[6];
+ int i;
+
+ mac_addr[0] = 0x02; /* Non OUI / registered MAC address */
+ mac_addr[1] = (reg_val >> 0) & 0xff;
+ reg_val = readl(SUNXI_SID_BASE + 0x0c);
+ mac_addr[2] = (reg_val >> 24) & 0xff;
+ mac_addr[3] = (reg_val >> 16) & 0xff;
+ mac_addr[4] = (reg_val >> 8) & 0xff;
+ mac_addr[5] = (reg_val >> 0) & 0xff;
+ 
+ for(i = 0; i < 6; i ++)
+ {
+ if(mac_addr[i] != *(p + i)){
+ eth_setenv_enetaddr("ethaddr", mac_addr);
+ break;
+ }
+ }
+ }
+ }
+#endif

return 0;
}
diff --git a/boards.cfg b/boards.cfg
index ebac426..a9e98c1 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -388,8 +388,8 @@ Active arm armv7 sunxi - sunxi
Active arm armv7 sunxi - sunxi Auxtek-T003 
sun5i:AUXTEK_T003,SPL,AXP152_POWER,STATUSLED=34 -
Active arm armv7 sunxi - sunxi Auxtek-T004 
sun5i:AUXTEK_T004,SPL,AXP152_POWER,STATUSLED=34 -
Active arm armv7 sunxi - sunxi ba10_tv_box sun4i:BA10_TV_BOX,SPL,SUNXI_EMAC -
-Active arm armv7 sunxi - sunxi Bananapi 
sun7i:BANANAPI,SPL,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPH(23),STATUSLED=244,STATUSLED1=245,FAST_MBUS
 -
-Active arm armv7 sunxi - sunxi Bananapi_FEL 
sun7i:BANANAPI,SPL_FEL,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPH(23),STATUSLED=244,STATUSLED1=245,FAST_MBUS
 -
+Active arm armv7 sunxi - sunxi Bananapi 
sun7i:BANANAPI,SPL,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPH(23),STATUSLED=248,FAST_MBUS
 -
+Active arm armv7 sunxi - sunxi Bananapi_FEL 
sun7i:BANANAPI,SPL_FEL,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPH(23),STATUSLED=248,FAST_MBUS
 -
Active arm armv7 sunxi - sunxi Coby_MID7042 sun4i:COBY_MID7042,SPL -
Active arm armv7 sunxi - sunxi Coby_MID8042 sun4i:COBY_MID8042,SPL -
Active arm armv7 sunxi - sunxi Coby_MID9742 sun4i:COBY_MID9742,SPL -
-- 
1.7.9.5




Tony Zhang

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

[Julian Calaby]

Hi Thierry,

On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
 wrote:
> On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
>> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> [...]
>> > simplefb doesn't deal at all with hardware details. It simply uses what
>> > firmware has set up, which is the only reason why it will work for many
>> > people. What is passed in via its device tree node is the minimum amount
>> > of information needed to draw something into the framebuffer. Also note
>> > that the simplefb device tree node is not statically added to a DTS file
>> > but needs to be dynamically generated by firmware at runtime.
>>
>> Which makes the whole even simpler, since the firmware already knows
>> all about which clocks it had to enable.
>
> It makes things very complicated in the firmware because it now needs to
> be able to generate DTB content that we would otherwise be able to do
> much easier with a text editor.

As far as the kernel is concerned, this is a solved problem.

Firmware is going to be doing some dark magic to set up the hardware
to be a dumb frame buffer and some other stuff to add the simplefb
device node - so by this point, adding the clocks (or whatever)
required by the hardware should be fairly uncomplicated - the firmware
already knows the hardware intimately. As for the actual device tree
manipulations, U-boot (or whatever) will probably just grow some
helper functions to make this simple.

Alternatively, it could simply add the relevant data to an existing
device node and munge it's compatible property so simplefb picks it
up.

>> > If we start extending the binding with board-level details we end up
>> > duplicating the device tree node for the proper video device. Also note
>> > that it won't stop at clocks. Other setups will require regulators to be
>> > listed in this device tree node as well so that they don't get disabled
>> > at late_initcall. And the regulator bindings don't provide a method to
>> > list an arbitrary number of clocks in a single property in the way that
>> > the clocks property works.
>> >
>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>> >
>> > Passing in clock information via the device tree already requires a non-
>> > trivial amount of code in the firmware. A similar amount of code would
>> > be necessary for each type of resource that needs to be kept enabled. In
>> > addition to the above some devices may also require resources that have
>> > no generic bindings. That just doesn't scale.
>> >
>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>>
>> You should really read that thread:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
>>
>> It's quite interesting, because you'll see that:
>> A) Your approach, even on the platform you're working on, doesn't
>>work. Or at least, isn't reliable.
>
> What platform exactly do you think I'm working on? Why do you think what
> I proposed isn't going to work or be reliable? I don't see any arguments
> in the thread that would imply that.
>
>> B) Other maintainers, precisely like Mark, came to the same conclusion
>>than Mike.
>
> Well, and others didn't.
>
> Also I think if you read that thread and look at my proposal it matches
> exactly what was discussed as one of the solutions at one point in the
> thread.
>
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> So, just to be clear, instead of doing a generic clk_get and
>> clk_prepare_enable, you're willing to do a just as much generic
>> clk_ignore_unused call?
>
> Yes.
>
>> How is that less generic?
>
> It's more generic. That's the whole point.
>

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 12:35:17PM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 12:18 PM, Thierry Reding
>  wrote:
> >> How is that less generic?
> >
> > It's more generic. That's the whole point.
> >
> > The difference is that with the solution I proposed we don't have to
> > keep track of all the resources. We know that firmware has set them up
> > and we know that a real driver will properly take them over at some
> > point, so duplicating what the real driver does within the simplefb
> > driver is just that, duplication. We don't allow duplication anywhere
> > else in the kernel, why should simplefb be an exception?
> >
> >> You know that you are going to call that for regulator, reset, power
> >> domains, just as you would have needed to with the proper API, unless
> >> that with this kind of solution, you would have to modify *every*
> >> framework that might interact with any resource involved in getting
> >> simplefb running?
> >
> > We have to add handling for every kind of resource either way. Also if
> > this evolves into a common pattern we can easily wrap it up in a single
> > function call.
> 
> disable_all_power_management(), as this is not limited to clocks.

Right. But it isn't all power management either. It just shouldn't turn
everything unused off. Clocks, regulators, power domains and so on which
are used can very well be power managed.

> >> Plus, speaking more specifically about the clocks, that won't prevent
> >> your clock to be shut down as a side effect of a later clk_disable
> >> call from another driver.
> 
> > Furthermore isn't it a bug for a driver to call clk_disable() before a
> > preceding clk_enable()? There are patches being worked on that will
> > enable per-user clocks and as I understand it they will specifically
> > disallow drivers to disable the hardware clock if other drivers are
> > still keeping them on via their own referenc.
> 
> Calling clk_disable() preceding clk_enable() is a bug.
> 
> Calling clk_disable() after clk_enable() will disable the clock (and
> its parents)
> if the clock subsystem thinks there are no other users, which is what will
> happen here.

Right. I'm not sure this is really applicable to this situation, though.
Either way, if there are other users of a clock then they will just as
likely want to modify the rate at which point simplefb will break just
as badly.

Thierry


pgpxfSBHORkJm.pgp
Description: PGP signature

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 11:44:19AM +0200, Michal Suchanek wrote:
> On 29 September 2014 10:54, Thierry Reding  wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> Hi Thierry,
> >>
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >>  wrote:
> >> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> >> > > > > I would think the memory should still be reserved anyway to 
> >> >> > > > > make sure
> >> >> > > > > nothing else is writing over it. And it's in the device tree 
> >> >> > > > > anyway
> >> >> > > > > because the driver needs to know where to put framebuffer 
> >> >> > > > > content. So
> >> >> > > > > the point I was trying to make is that we can't treat the 
> >> >> > > > > memory in the
> >> >> > > > > same way as clocks because it needs to be explicitly managed. 
> >> >> > > > > Whereas
> >> >> > > > > clocks don't. The driver is simply too generic to know what to 
> >> >> > > > > do with
> >> >> > > > > the clocks.
> >> >> > > >
> >> >> > > > You agreed on the fact that the only thing we need to do with the
> >> >> > > > clocks is claim them. Really, I don't find what's complicated 
> >> >> > > > there
> >> >> > > > (or not generic).
> >> >> > >
> >> >> > > That's not what I agreed on. What I said is that the only thing we 
> >> >> > > need
> >> >> > > to do with the clocks is nothing. They are already in the state that
> >> >> > > they need to be.
> >> >> >
> >> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> >> > the clock running, and both the solution you've been giving and this
> >> >> > patch do so in a generic way.
> >> >> >
> >> >> > > > > It doesn't know what frequency they should be running at
> >> >> > > >
> >> >> > > > We don't care about that. Just like we don't care about which
> >> >> > > > frequency is the memory bus running at. It will just run at 
> >> >> > > > whatever
> >> >> > > > frequency is appropriate.
> >> >> > >
> >> >> > > Exactly. And you shouldn't have to care about them at all. Firmware 
> >> >> > > has
> >> >> > > already configured the clocks to run at the correct frequencies, 
> >> >> > > and it
> >> >> > > has made sure that they are enabled.
> >> >> > >
> >> >> > > > > or what they're used for
> >> >> > > >
> >> >> > > > And we don't care about that either. You're not interested in what
> >> >> > > > output the framebuffer is setup to use, which is pretty much the 
> >> >> > > > same
> >> >> > > > here, this is the same thing here.
> >> >> > >
> >> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> >> > > cares about is the memory it should be using and the format of the
> >> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> >> > > else is assumed to have been set up.
> >> >> > >
> >> >> > > Including clocks.
> >> >> >
> >> >> > We're really discussing in circles here.
> >> >> >
> >> >> > Mike?
> >> >> >
> >> >>
> >> >> -EHIGHLATENCYRESPONSE
> >> >>
> >> >> I forgot about this thread. Sorry.
> >> >>
> >> >> In an attempt to provide the least helpful answer possible, I will stay
> >> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> >> and the related reserved memory discussion.
> >> >>
> >> >> A few times in this thread it is stated that we can't prevent unused
> >> >> clocks from being disabled. That is only partially true.
> >> >>
> >> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> >> of this.
> >> >>
> >> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> >> the right driver claims me". That would be an external or alternative
> >> >> method for preventing a clock from being disabled. We have a method for
> >> >> preventing clocks from being disabled. It is as follows:
> >> >>
> >> >> struct clk *my_clk = clk_get(...);
> >> >> clk_prepare_enable(my_clk);
> >> >>
> >> >> That is how it should be done. Period.
> >> >>
> >> >> With that said I think that Luc's approach is very sensible. I'm not
> >> >> sure what purpose in the universe DT is supposed to serve if not for
> >> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> >> people. The hardware details of how it is hooked up at the board level
> >> >> can all be hidden behind stable DT bindings that everyone already uses.

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

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 12:18 PM, Thierry Reding
 wrote:
>> How is that less generic?
>
> It's more generic. That's the whole point.
>
> The difference is that with the solution I proposed we don't have to
> keep track of all the resources. We know that firmware has set them up
> and we know that a real driver will properly take them over at some
> point, so duplicating what the real driver does within the simplefb
> driver is just that, duplication. We don't allow duplication anywhere
> else in the kernel, why should simplefb be an exception?
>
>> You know that you are going to call that for regulator, reset, power
>> domains, just as you would have needed to with the proper API, unless
>> that with this kind of solution, you would have to modify *every*
>> framework that might interact with any resource involved in getting
>> simplefb running?
>
> We have to add handling for every kind of resource either way. Also if
> this evolves into a common pattern we can easily wrap it up in a single
> function call.

disable_all_power_management(), as this is not limited to clocks.

>> Plus, speaking more specifically about the clocks, that won't prevent
>> your clock to be shut down as a side effect of a later clk_disable
>> call from another driver.

> Furthermore isn't it a bug for a driver to call clk_disable() before a
> preceding clk_enable()? There are patches being worked on that will
> enable per-user clocks and as I understand it they will specifically
> disallow drivers to disable the hardware clock if other drivers are
> still keeping them on via their own referenc.

Calling clk_disable() preceding clk_enable() is a bug.

Calling clk_disable() after clk_enable() will disable the clock (and
its parents)
if the clock subsystem thinks there are no other users, which is what will
happen here.

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:
> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
[...]
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> > people. What is passed in via its device tree node is the minimum amount
> > of information needed to draw something into the framebuffer. Also note
> > that the simplefb device tree node is not statically added to a DTS file
> > but needs to be dynamically generated by firmware at runtime.
> 
> Which makes the whole even simpler, since the firmware already knows
> all about which clocks it had to enable.

It makes things very complicated in the firmware because it now needs to
be able to generate DTB content that we would otherwise be able to do
much easier with a text editor.

> > If we start extending the binding with board-level details we end up
> > duplicating the device tree node for the proper video device. Also note
> > that it won't stop at clocks. Other setups will require regulators to be
> > listed in this device tree node as well so that they don't get disabled
> > at late_initcall. And the regulator bindings don't provide a method to
> > list an arbitrary number of clocks in a single property in the way that
> > the clocks property works.
> > 
> > There may be also resets involved. Fortunately the reset framework is
> > minimalistic enough not to care about asserting all unused resets at
> > late_initcall. And other things like power domains may also need to be
> > kept on.
> > 
> > Passing in clock information via the device tree already requires a non-
> > trivial amount of code in the firmware. A similar amount of code would
> > be necessary for each type of resource that needs to be kept enabled. In
> > addition to the above some devices may also require resources that have
> > no generic bindings. That just doesn't scale.
> > 
> > The only reasonable thing for simplefb to do is not deal with any kind
> > of resource at all (except perhaps area that contains the framebuffer
> > memory).
> 
> You should really read that thread:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284726.html
> 
> It's quite interesting, because you'll see that:
> A) Your approach, even on the platform you're working on, doesn't
>work. Or at least, isn't reliable.

What platform exactly do you think I'm working on? Why do you think what
I proposed isn't going to work or be reliable? I don't see any arguments
in the thread that would imply that.

> B) Other maintainers, precisely like Mark, came to the same conclusion
>than Mike.

Well, and others didn't.

Also I think if you read that thread and look at my proposal it matches
exactly what was discussed as one of the solutions at one point in the
thread.

> > So how about instead of requiring resources to be explicitly claimed we
> > introduce something like the below patch? The intention being to give
> > "firmware device" drivers a way of signalling to the clock framework
> > that they need rely on clocks set up by firmware and when they no longer
> > need them. This implements essentially what Mark (CC'ing again on this
> > subthread) suggested earlier in this thread. Basically, it will allow
> > drivers to determine the time when unused clocks are really unused. It
> > will of course only work when used correctly by drivers. For the case of
> > simplefb I'd expect its .probe() implementation to call the new
> > clk_ignore_unused() function and once it has handed over control of the
> > display hardware to the real driver it can call clk_unignore_unused() to
> > signal that all unused clocks that it cares about have now been claimed.
> > This is "reference counted" and can therefore be used by more than a
> > single driver if necessary. Similar functionality could be added for
> > other resource subsystems as needed.
> 
> So, just to be clear, instead of doing a generic clk_get and
> clk_prepare_enable, you're willing to do a just as much generic
> clk_ignore_unused call?

Yes.

> How is that less generic?

It's more generic. That's the whole point.

The difference is that with the solution I proposed we don't have to
keep track of all the resources. We know that firmware has set them up
and we know that a real driver will properly take them over at some
point, so duplicating what the real driver does within the simplefb
driver is just that, duplication. We don't allow duplication anywhere
else in the kernel, why should simplefb be an exception?

> You know that you are going to call that for regulator, reset, power
> domains, just as you would have needed to with the proper API, unless
> that with this kind of solution, you would have to modify *every*
> framework that might interact with any resource involved in getting
> simplefb running?

We have to add handling for every kind of resource either way. Also if
this evolves into a common patt

Re: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s

[ke...@allwinnertech.com]

Hi All,

I have put the documents on github, and the url is 
https://github.com/allwinner-zh/documents.git
Thanks Simos, Henrik and Luc's suggestion. And other documents will be upated 
to here when released.



Best Regards,
kevin.z.m



From: HenrikNordström
Date: 2014-09-29 08:46
To: linux-sunxi@googlegroups.com
CC: sh...@allwinnertech.com; Meng 
Zhang
Subject: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user 
manual) for A10, A10s, A13, A20, A31, A31s
sön 2014-09-28 klockan 02:18 +0200 skrev Luc Verhaegen:

> Why didn't someone from Allwinner send these documents in him/herself?

The current person discussion the matter with Allwiner was Simos, who is
part of the linux-sunxi community. Allwinner sent current versions of
the documents to Simos for distribution in the community. What is wrong?

Mailing the full set of documents as attachments directly to the
mailinglist is not appropriate. And for some strange and unknown reason
Allwinner do not appear to have a public document archive for this kind
of documents themselves, and seems to only distribute them via email to
their customers when requested.

The real question is why AW do not make the documents available in
public themselves, and likewise why they do not have a public git
repository for SDK sources etc (github or elsewhere).

Regards
Henrik

NOTICE: This e-mail and any included attachments are intended only for the sole 
use of named and intended recipient (s) only. If you are the named and intended 
recipient, please note that the information contained in this email and its 
embedded files are confidential and privileged. If you are neither the intended 
nor named recipient, you are hereby notified that any unauthorized review, use, 
disclosure, dissemination, distribution, or copying of this communication, or 
any of its contents, is strictly prohibited. Please reply to the sender and 
destroy the original message and all your records of this message (whether 
electronic or otherwise). Furthermore, you should not disclose to any other 
person, use, copy or disseminate the contents of this e-mail and/or the 
documents accompanying it.

-- 
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 29 September 2014 10:54, Thierry Reding  wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> Hi Thierry,
>>
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>>  wrote:
>> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> >> > > > > I would think the memory should still be reserved anyway to make 
>> >> > > > > sure
>> >> > > > > nothing else is writing over it. And it's in the device tree 
>> >> > > > > anyway
>> >> > > > > because the driver needs to know where to put framebuffer 
>> >> > > > > content. So
>> >> > > > > the point I was trying to make is that we can't treat the memory 
>> >> > > > > in the
>> >> > > > > same way as clocks because it needs to be explicitly managed. 
>> >> > > > > Whereas
>> >> > > > > clocks don't. The driver is simply too generic to know what to do 
>> >> > > > > with
>> >> > > > > the clocks.
>> >> > > >
>> >> > > > You agreed on the fact that the only thing we need to do with the
>> >> > > > clocks is claim them. Really, I don't find what's complicated there
>> >> > > > (or not generic).
>> >> > >
>> >> > > That's not what I agreed on. What I said is that the only thing we 
>> >> > > need
>> >> > > to do with the clocks is nothing. They are already in the state that
>> >> > > they need to be.
>> >> >
>> >> > Claim was probably a poor choice of words, but still. We have to keep
>> >> > the clock running, and both the solution you've been giving and this
>> >> > patch do so in a generic way.
>> >> >
>> >> > > > > It doesn't know what frequency they should be running at
>> >> > > >
>> >> > > > We don't care about that. Just like we don't care about which
>> >> > > > frequency is the memory bus running at. It will just run at whatever
>> >> > > > frequency is appropriate.
>> >> > >
>> >> > > Exactly. And you shouldn't have to care about them at all. Firmware 
>> >> > > has
>> >> > > already configured the clocks to run at the correct frequencies, and 
>> >> > > it
>> >> > > has made sure that they are enabled.
>> >> > >
>> >> > > > > or what they're used for
>> >> > > >
>> >> > > > And we don't care about that either. You're not interested in what
>> >> > > > output the framebuffer is setup to use, which is pretty much the 
>> >> > > > same
>> >> > > > here, this is the same thing here.
>> >> > >
>> >> > > That's precisely what I've been saying. The only thing that simplefb
>> >> > > cares about is the memory it should be using and the format of the
>> >> > > pixels (and how many of them) it writes into that memory. Everything
>> >> > > else is assumed to have been set up.
>> >> > >
>> >> > > Including clocks.
>> >> >
>> >> > We're really discussing in circles here.
>> >> >
>> >> > Mike?
>> >> >
>> >>
>> >> -EHIGHLATENCYRESPONSE
>> >>
>> >> I forgot about this thread. Sorry.
>> >>
>> >> In an attempt to provide the least helpful answer possible, I will stay
>> >> clear of all of the stuff relating to "how simple should simplefb be"
>> >> and the related reserved memory discussion.
>> >>
>> >> A few times in this thread it is stated that we can't prevent unused
>> >> clocks from being disabled. That is only partially true.
>> >>
>> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> >> being disabled at late_initcall-time by a clock "garbage collector"
>> >> mechanism. Maxime and others familiar with the clock framework are aware
>> >> of this.
>> >>
>> >> What the framework doesn't do is to allow for a magic flag in DT, in
>> >> platform_data or elsewhere that says, "don't let me get turned off until
>> >> the right driver claims me". That would be an external or alternative
>> >> method for preventing a clock from being disabled. We have a method for
>> >> preventing clocks from being disabled. It is as follows:
>> >>
>> >> struct clk *my_clk = clk_get(...);
>> >> clk_prepare_enable(my_clk);
>> >>
>> >> That is how it should be done. Period.
>> >>
>> >> With that said I think that Luc's approach is very sensible. I'm not
>> >> sure what purpose in the universe DT is supposed to serve if not for
>> >> _this_exact_case_. We have a nice abstracted driver, usable by many
>> >> people. The hardware details of how it is hooked up at the board level
>> >> can all be hidden behind stable DT bindings that everyone already uses.
>> >
>> > simplefb doesn't deal at all with hardware details. It simply uses what
>> > firmware has set up, which is the only reason why it will work for many
>>
>> It doesn't deal with "hardware details for hardware components for which
>> no driver is available (yet)". That's why the hardware is stil

Re: [linux-sunxi] How to enable bluetooth power

[Toroshin Dmitry]

I changed code to this:
<-->sw_usb_enable_hcd(usb_wifi_host);
<-->sw_usb_enable_hcd(1);
<-->u32 pio_hdle = gpio_request_ex("bt_para", NULL);
<-->if(pio_hdle)
<-->{   gpio_write_one_pin_value(pio_hdle, 1, "bt_wake");
<--><-->gpio_write_one_pin_value(pio_hdle, 1, "bt_pwren");
<--><-->//gpio_release(pio_hdle, 2);
<-->}
<-->u32 pio_hdle2 = gpio_request_ex("3g_para", NULL);
<-->gpio_write_one_pin_value(pio_hdle2, 1, "3g_power_switch");
<-->gpio_write_one_pin_value(pio_hdle2, 1, "3g_pwr");
<-->gpio_write_one_pin_value(pio_hdle2, 1, "3g_wakeup");
Now i can see modem in lsusb, but it's unknown and is's need to force 
usbserial module to use it.
Bluetooth still does not work.
sunxi_keyboard works after adding:
[tabletkeys_para]
tabletkeys_used=1
key0_code = 114
key1_code = 115





to fex.

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 11:10:53AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
>  wrote:
> > On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> >> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> >> (CC gregkh and lkml, for driver core)
> >>
> >> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
> >>  wrote:
> >> > If we start extending the binding with board-level details we end up
> >> > duplicating the device tree node for the proper video device. Also note
> >> > that it won't stop at clocks. Other setups will require regulators to be
> >> > listed in this device tree node as well so that they don't get disabled
> >> > at late_initcall. And the regulator bindings don't provide a method to
> >> > list an arbitrary number of clocks in a single property in the way that
> >> > the clocks property works.
> >>
> >> Then (optional) regulator support needs to be added.
> >
> > Can you elaborate?
> 
> I'm not so familiar with regulators, but I guess it's similar to clocks?

The bindings are different. Essentially what you use is a *-supply
property per regulator. There is no way to specify more than one
regulator in a single property.

So if you want to keep that generic you have to do crazy things like:

simplefb {
enable-0-supply = <®1>;
enable-1-supply = <®2>;
...
};

I suppose a more generic supplies property could be created to support
this use-case, but I think this kind of proves my point. The only way
that the original proposal is going to work for other resources is if
they follow the same kind of binding. I don't think it makes sense to
introduce such a prerequisite merely because it would make life easy
for some exotic driver with a very specific application.

> > And then all of a sudden something that was supposed to be simple and
> > generic needs to know the specifics of some hardware device.
> 
> And suddenly we wish we could write a real driver and put the stuff in
> the DTS, not DTB...

Oh, there's no doubt a real driver would be preferrable. Note that
simplefb is only meant to be a shim to pass a framebuffer from firmware
to kernel. In some cases it can be used with longer lifetime, like for
example if you really want to have graphical output but the real driver
isn't there yet.

Being a shim driver is precisely the reason why I think the binding
shouldn't be extended to cover all possible types of resources. That
should all go into the binding for the real device.

> >> > The only reasonable thing for simplefb to do is not deal with any kind
> >> > of resource at all (except perhaps area that contains the framebuffer
> >> > memory).
> >> >
> >> > So how about instead of requiring resources to be explicitly claimed we
> >> > introduce something like the below patch? The intention being to give
> >> > "firmware device" drivers a way of signalling to the clock framework
> >> > that they need rely on clocks set up by firmware and when they no longer
> >> > need them. This implements essentially what Mark (CC'ing again on this
> >> > subthread) suggested earlier in this thread. Basically, it will allow
> >> > drivers to determine the time when unused clocks are really unused. It
> >> > will of course only work when used correctly by drivers. For the case of
> >> > simplefb I'd expect its .probe() implementation to call the new
> >> > clk_ignore_unused() function and once it has handed over control of the
> >> > display hardware to the real driver it can call clk_unignore_unused() to
> >> > signal that all unused clocks that it cares about have now been claimed.
> >> > This is "reference counted" and can therefore be used by more than a
> >> > single driver if necessary. Similar functionality could be added for
> >> > other resource subsystems as needed.
> >>
> >> This still won't work for modules, right? Or am I missing something?
> >> With modules you will never know in advance what will be used and what
> >> won't be used, so you need to keep all clocks, regulators, PM domains, ...
> >> up and running?
> >
> > No. The way this works is that your firmware shim driver, simplefb in
> > this case, will call clk_ignore_unused() to tell the clock framework
> > that it uses clocks set up by the firmware, and therefore requests that
> > no clocks should be considered unused (for now). Later on when the
> > proper driver has successfully taken over from the shim driver, the shim
> > driver can unregister itself and call clk_unignore_unused(), which will
> > drop its "reference" on the unused clocks. When all references have been
> > dropped the clock framework will then disable all remaining unused
> > clocks.
> 
> So the shim must be built-in, not modular.

Correct. Making it a module isn't very useful in my opinion. You'd loose
all the advantages.

Thierry


pgpKAyGHybPqz.pgp
Description: PGP signature

Re: [linux-sunxi] How to enable bluetooth power

[Toroshin Dmitry]

On Monday, September 29, 2014 8:53:39 AM UTC+7, Julian Calaby wrote:
>
> Hi, 
>
> On Sat, Sep 27, 2014 at 11:22 PM,  > 
> wrote: 
> > суббота, 27 сентября 2014 г., 19:03:26 UTC+7 пользователь Julian Calaby 
> написал: 
> >> Hi Toroshin, 
> >> 
> >> 
> >> 
> >> On Sat, Sep 27, 2014 at 9:13 PM, Toroshin Dmitry  > wrote: 
> >> 
> >> > I have unnamed A10 tablet with RDA bluetooth on serial. 
> >> 
> >> > Bluetooth adapter seems to be disabled by default. 
> >> 
> >> > In stock gpl-violating kernel it controls by 
> /sys/class/usb_wifi/rtl_wifi/bt 
> >> 
> >> > hciattach shows this before bt enabled: 
> >> 
> >> 
> >> 
> >> We'll be able to give you much better assistance with this if you go 
> >> 
> >> through the New Device Howto: http://linux-sunxi.org/New_Device_howto 
> >> 
> >> 
> >> 
> >> > ./hciattach -n -s 115200 /dev/ttyS2 rda 150 flow 
> >> 
> >> > opt=110 
> >> 
> >> > opt=115 
> >> 
> >> > chenjieaaa --debug argc=8 n=0 opt 
> >> 
> >> > =/dev/ttyS2 
> >> 
> >> > chenjieaaa --debug argc=8 n=1 opt 
> =rda 
> >> 
> >> > chenjieaaa --debug argc=8 n=2 opt 
> =150 
> >> 
> >> > chenjieaaa --debug argc=8 n=3 opt 
> =flow 
> >> 
> >> > init_uart -> 
> >> 
> >> > flags =0 
> >> 
> >> > u->init fd =  3 
> >> 
> >>  rda_587x 
> >> 
> >> >  debug   --val 0 u->speed =150 
> u->bdaddr=41:57:73:01:02:03 
> >> 
> >> > rda_init-->bt debug 
> >> 
> >> > RDABT_core_Intialization-->bt debug 
> >> 
> >> > rdabt_get_chipid-->bt debug 
> >> 
> >> > Initialization timed out. 
> >> 
> >> > 
> >> 
> >> > After echoing on to /sys/class/usb_wifi/rtl_wifi/bt initialisation 
> >> 
> >> > successful: 
> >> 
> >> > 
> >> 
> >> > ./hciattach -n -s 115200 /dev/ttyS2 rda 150 flow 
> >> 
> >> > opt=110 
> >> 
> >> > opt=115 
> >> 
> >> > chenjieaaa --debug argc=8 n=0 opt 
> >> 
> >> > =/dev/ttyS2 
> >> 
> >> > chenjieaaa --debug argc=8 n=1 opt 
> =rda 
> >> 
> >> > chenjieaaa --debug argc=8 n=2 opt 
> =150 
> >> 
> >> > chenjieaaa --debug argc=8 n=3 opt 
> =flow 
> >> 
> >> > init_uart -> 
> >> 
> >> > flags =0 
> >> 
> >> > u->init fd =  3 
> >> 
> >>  rda_587x 
> >> 
> >> >  debug   --val 0 u->speed =150 
> u->bdaddr=41:57:73:01:02:03 
> >> 
> >> > rda_init-->bt debug 
> >> 
> >> > RDABT_core_Intialization-->bt debug 
> >> 
> >> > rdabt_get_chipid-->bt debug 
> >> 
> >> > 5875y is ok -->bt debug 
> >> 
> >> > rda_init1 write here 
> >> 
> >> > rda_set_bdaddr 1-->bt debug 
> >> 
> >> > BCM_BT start Write_BD_ADDR 
> >> 
> >> > mac=41:57:73:01:02:03 
> >> 
> >> > rda_init2 write here 
> >> 
> >> > rda_init2 write here 
> >> 
> >> > val 0 u->speed =150 u->bdaddr=41:57:73:01:02:03 
> >> 
> >> > init_uart--u->flags=1 
> >> 
> >> > rda_setup_flow_ctl -flow 
> >> 
> >> > rda_setup_flow_ctl> i=0  num_send=14 
> >> 
> >> > rda_setup_flow_ctl> i=1  num_send=14 
> >> 
> >> > rda_setup_flow_ctl 
> >> 
> >> > Device setup complete 
> >> 
> >> > sigdelset OK 
> >> 
> >> > 
> >> 
> >> > This is bt_para section: 
> >> 
> >> > [bt_para] 
> >> 
> >> > bt_used = 1 
> >> 
> >> > bt_uart_id = 2 
> >> 
> >> > bt_mod_type = 1 
> >> 
> >> > bt_pwren = port:PH11<1> 
> >> 
> >> > bt_wake = port:PI20<1> 
> >> 
> >> > bt_vbat = port:PH12<1> 
> >> 
> >> > It seems that i need enaple power on PH11, but how to do that? 
> >> 
> >> 
> >> 
> >> This should be handled by the driver, which kernel are you using? 
> >> 
> >> 
> >> 
> >> > What full fex: http://dpaste.com/2C4HPFZ 
> >> 
> >> > Also csi camera, sun4i-keyboard and internal usb modem does not work. 
> >> 
> >> 
> >> 
> >> With more info, we should be able to help you with this. 
> >> 
> >> 
> >> 
> >> Also, what do you mean by a "usb modem" is there a phone socket on the 
> device? 
> >> 
> >> 
> >> 
> >> Thanks, 
> >> 
> >> 
> >> 
> >> -- 
> >> 
> >> Julian Calaby 
> >> 
> >> 
> >> 
> >> Email: julian...@gmail.com  
> >> 
> >> Profile: http://www.google.com/profiles/julian.calaby/ 
> > 
> > Yes, there is a phone SIM socket on main board. Modem is on separate 
> board, connected with USB and SIM pins. 
>
> Ah, that makes sense. 
>
> I'm guessing this is some generic USB 3G modem, there should be 
> support for it in the kernel, the driver probably isn't compiled into 
> your kernel. What does "lsusb" output for it? 
>
> > I can add page, but cannot provide board images and get a serial console 
> because i have no camera and voltage-compatible serial adapter. And i 
> cannot fully uncover case because i'

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

[Maxime Ripard]

On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-02 02:25:08)
> > > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > > I would think the memory should still be reserved anyway to make 
> > > > > > sure
> > > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > > because the driver needs to know where to put framebuffer content. 
> > > > > > So
> > > > > > the point I was trying to make is that we can't treat the memory in 
> > > > > > the
> > > > > > same way as clocks because it needs to be explicitly managed. 
> > > > > > Whereas
> > > > > > clocks don't. The driver is simply too generic to know what to do 
> > > > > > with
> > > > > > the clocks.
> > > > > 
> > > > > You agreed on the fact that the only thing we need to do with the
> > > > > clocks is claim them. Really, I don't find what's complicated there
> > > > > (or not generic).
> > > > 
> > > > That's not what I agreed on. What I said is that the only thing we need
> > > > to do with the clocks is nothing. They are already in the state that
> > > > they need to be.
> > > 
> > > Claim was probably a poor choice of words, but still. We have to keep
> > > the clock running, and both the solution you've been giving and this
> > > patch do so in a generic way.
> > > 
> > > > > > It doesn't know what frequency they should be running at
> > > > > 
> > > > > We don't care about that. Just like we don't care about which
> > > > > frequency is the memory bus running at. It will just run at whatever
> > > > > frequency is appropriate.
> > > > 
> > > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > > already configured the clocks to run at the correct frequencies, and it
> > > > has made sure that they are enabled.
> > > > 
> > > > > > or what they're used for
> > > > > 
> > > > > And we don't care about that either. You're not interested in what
> > > > > output the framebuffer is setup to use, which is pretty much the same
> > > > > here, this is the same thing here.
> > > > 
> > > > That's precisely what I've been saying. The only thing that simplefb
> > > > cares about is the memory it should be using and the format of the
> > > > pixels (and how many of them) it writes into that memory. Everything
> > > > else is assumed to have been set up.
> > > > 
> > > > Including clocks.
> > > 
> > > We're really discussing in circles here.
> > > 
> > > Mike?
> > > 
> > 
> > -EHIGHLATENCYRESPONSE
> > 
> > I forgot about this thread. Sorry.
> > 
> > In an attempt to provide the least helpful answer possible, I will stay
> > clear of all of the stuff relating to "how simple should simplefb be"
> > and the related reserved memory discussion.
> > 
> > A few times in this thread it is stated that we can't prevent unused
> > clocks from being disabled. That is only partially true.
> > 
> > The clock framework DOES provide a flag to prevent UNUSED clocks from
> > being disabled at late_initcall-time by a clock "garbage collector"
> > mechanism. Maxime and others familiar with the clock framework are aware
> > of this.
> > 
> > What the framework doesn't do is to allow for a magic flag in DT, in
> > platform_data or elsewhere that says, "don't let me get turned off until
> > the right driver claims me". That would be an external or alternative
> > method for preventing a clock from being disabled. We have a method for
> > preventing clocks from being disabled. It is as follows:
> > 
> > struct clk *my_clk = clk_get(...);
> > clk_prepare_enable(my_clk);
> > 
> > That is how it should be done. Period.
> > 
> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.
> 
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

Which makes the whole even simpler, since the firmware already knows
all about which clocks it had to enable.

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed

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

[Geert Uytterhoeven]

Hi Thierry,

On Mon, Sep 29, 2014 at 10:54 AM, Thierry Reding
 wrote:
> On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
>> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
>> (CC gregkh and lkml, for driver core)
>>
>> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>>  wrote:
>> > If we start extending the binding with board-level details we end up
>> > duplicating the device tree node for the proper video device. Also note
>> > that it won't stop at clocks. Other setups will require regulators to be
>> > listed in this device tree node as well so that they don't get disabled
>> > at late_initcall. And the regulator bindings don't provide a method to
>> > list an arbitrary number of clocks in a single property in the way that
>> > the clocks property works.
>>
>> Then (optional) regulator support needs to be added.
>
> Can you elaborate?

I'm not so familiar with regulators, but I guess it's similar to clocks?

>> > There may be also resets involved. Fortunately the reset framework is
>> > minimalistic enough not to care about asserting all unused resets at
>> > late_initcall. And other things like power domains may also need to be
>> > kept on.
>>
>> Fortunately, unlike clocks, PM domains are first class citizens in the
>> device framework, as they're handled by the driver core.
>> So just adding a power-domains property to DTS will work, without any
>> driver change.
>
> Well, the device driver would also need to call into the PM runtime
> framework to enable all the first class citizen magic. But even if it
> were to do that, you'd still need to add all the domains to the DTB.

Powering up domains can be done solely by the device-specific PM
domain code, without PM runtime. If simplefb is tied to the PM domain
and doesn't do any PM runtime, the domain will stay powered on
(only unused PM domains are powered down via late_initcall).

> Note that I'm saying DT*B* here, because the firmware needs to fill in
> those properties after the DTS has been compiled. And since most of
> these resources are linked via phandle you actually need to resolve
> these first before you can fill in the new properties of this
> dynamically created node.
>
> So firmware needs to know exactly what device tree node to look for,
> find a corresponding phandle and then put the phandle value in the
> simplefb device tree node. And it needs to know intimate details about
> the clock provider binding because it needs to add an appropriate
> specifier, too.

Indeed. Complicated.

> And then all of a sudden something that was supposed to be simple and
> generic needs to know the specifics of some hardware device.

And suddenly we wish we could write a real driver and put the stuff in
the DTS, not DTB...

>> > The only reasonable thing for simplefb to do is not deal with any kind
>> > of resource at all (except perhaps area that contains the framebuffer
>> > memory).
>> >
>> > So how about instead of requiring resources to be explicitly claimed we
>> > introduce something like the below patch? The intention being to give
>> > "firmware device" drivers a way of signalling to the clock framework
>> > that they need rely on clocks set up by firmware and when they no longer
>> > need them. This implements essentially what Mark (CC'ing again on this
>> > subthread) suggested earlier in this thread. Basically, it will allow
>> > drivers to determine the time when unused clocks are really unused. It
>> > will of course only work when used correctly by drivers. For the case of
>> > simplefb I'd expect its .probe() implementation to call the new
>> > clk_ignore_unused() function and once it has handed over control of the
>> > display hardware to the real driver it can call clk_unignore_unused() to
>> > signal that all unused clocks that it cares about have now been claimed.
>> > This is "reference counted" and can therefore be used by more than a
>> > single driver if necessary. Similar functionality could be added for
>> > other resource subsystems as needed.
>>
>> This still won't work for modules, right? Or am I missing something?
>> With modules you will never know in advance what will be used and what
>> won't be used, so you need to keep all clocks, regulators, PM domains, ...
>> up and running?
>
> No. The way this works is that your firmware shim driver, simplefb in
> this case, will call clk_ignore_unused() to tell the clock framework
> that it uses clocks set up by the firmware, and therefore requests that
> no clocks should be considered unused (for now). Later on when the
> proper driver has successfully taken over from the shim driver, the shim
> driver can unregister itself and call clk_unignore_unused(), which will
> drop its "reference" on the unused clocks. When all references have been
> dropped the clock framework will then disable all remaining unused
> clocks.

So the shim must be built-in, not modular.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- T

Re: [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards

[Arnd Gronenberg]

On 09/29/2014 12:09 AM, Siarhei Siamashka wrote:

On Sun, 28 Sep 2014 21:34:57 +0200
Arnd Gronenberg  wrote:


On 09/28/2014 05:58 PM, Hans de Goede wrote:

[...]

On 09/18/2014 06:07 PM, Siarhei Siamashka wrote:

Which revision of A10-OLinuXino-LIME do you have? Revision A is known
to have troubles running stable at 1008MHz CPU clock speed, as confirmed
on a sample set of two boards (mine and Oliver Schinagl's):
  https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html

I have a revision A board.

My Olimex A10 OLinuXino Lime is also labelled "Rev. A"... It is running
stable at 1008MHz and I just tried Olivers djpeg test without any problems.

I'm running Hans' u-boot-sunxi 2014.10-rc1-g7190869 and Linux mainline
3.17.0-rc1-00158-g451fd72.

Thanks for trying the test and sharing the results. You are extending
our sample set from 2 boards to 3 (by the whole 50%) :-)

But could you please check whether you really have libjpeg-turbo
(with NEON optimizations) and not libjpeg from IJG? I did mention
libjpeg-turbo a few times in my original e-mail, however somehow failed
to communicate that it is strictly required to reproduce the problem.
Sorry about this. One of the commenters in the old discussion thread
already fell into this trap :-( Later I provided a script for automating
everything by using a ruby script. The script performs downloading and
compiling the "right" libjpeg-turbo and then runs tests for all cpufreq
operating points. But since the mainline kernel does not have cpufreq
support yet, this script will not help us here (and is not really
needed).

Anyway, please check whether you have libjpeg-turbo by running
"djpeg -v" command. If your distro happens to have IJG libjpeg instead
of libjpeg-turbo, then you can download and compile libjpeg-turbo from
sources (it is quite a small package and does not require any
dependencies). After that, you can run the test as demonstrated in
the examples below.

Output from djpeg -v
:
libjpeg-turbo version 1.3.1 (build 20140403)
Copyright (C) 1991-2012 Thomas G. Lane, Guido Vollbeding
Copyright (C) 1999-2006 MIYASAKA Masaru
Copyright (C) 2009 Pierre Ossman for Cendio AB
Copyright (C) 2009-2014 D. R. Commander
Copyright (C) 2009-2011 Nokia Corporation and/or its subsidiary(-ies)

Emulating The Independent JPEG Group's software, version 8d 15-Jan-2012



My results from A10-Lime revision A with the sunxi-3.4 kernel and
u-boot v2014.10-rc2:

$ djpeg -v
libjpeg-turbo version 1.3.0 (build 20130811)

$ cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg
$ while true ; do djpeg A10-LIME.jpg | md5sum ; done
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
6047ca65e1412dd3f53b250239e4558b  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
9d8eb11018cca04f70883c6ed9ddb9c6  -
7d2a4baa11e7015e2b8ae5717fce699b  -
513bd48bcd3a67705324ec8658646e7d  -
f61c7c8f42b86ede28d48dfb350efd64  -
50a3b1ea14994d19a66238f2414d9f5c  -
674f968fe8d7c79b2f7116c94b2fb02c  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
b57efa7bb81263a93f69fcbbbd06d590  -
d1627d8fd02f54e0154fcced72be637b  -
ab92721819073d0fb4dd2a7a67afb0fc  -
79cf9706c29c19b9325d3e04f34b5059  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
9ba81185fd5ed48277cc590fdb323955  -
d43cdb0215bae6de33b7921b20c5545f  -
d1ef0584fdff38c84a7d24a32fde4de9  -
1cef1e0202605a93870279f23d93287f  -
f7fd0ae6b3beda26f61c2be566224ac3  -
c346e833833f9b35093be336cadbcbc2  -
02c6e7e19882f438e5a9123a0d3e7ea2  -
b9d788d94a469b3bad20a997a039ce88  -
8545180d6384a6319fbf672052d61549  -
455b8da5c39b21b5104c12b6d02e9ff8  -
670df0c3bf6becf5e4378e336d193f45  -
07e922c9510d9d75f701317ada24d1f9  -
8cdae0aa48061da5c45ac81159bdac53  -
4f3b47ad5603f7253c0a4b13a61987a5  -
02f6175d5fb8672e69c7e433451b5dbc  -
1440adb6576c6d02cf05c31b3c2c2b7c  -
618a736628096581dfd2d5421e061235  -
2a791022a39f7e8d57efa50cd801007b  -
44d2e8dd4a205d3aadcfc25a446fe06e  -
72e2d96eb5e0ea987763cfaa1f3ca0a5  -
4f4c11e23f09f2923f925e6bb0a88deb  -
f6ce3826e0e91ca75fbca378f21a6a72  -
6d2c6ac6eb8c96cad5b19e3287192802  -
8db6a3c5fb031317eb352110261e23fd  -

And results with the mainline kernel and u-boot v2014.10-rc2:

$ djpeg -v
libjpeg-turbo version 1.3.0 (build 20130811)

$ cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg
$ while true ; do djpeg A10-LIME.jpg | md5sum ; done
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88c5720b0dc8d8ece43099  -
bf66d2bd1a88

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

[Thierry Reding]

On Mon, Sep 29, 2014 at 10:27:41AM +0200, Geert Uytterhoeven wrote:
> Hi Thierry,
> 
> (CC linux-pm, as PM is the real reason behind disabling unused clocks)
> (CC gregkh and lkml, for driver core)
> 
> On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
>  wrote:
> > On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> >> Quoting Maxime Ripard (2014-09-02 02:25:08)
> >> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> >> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> >> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> >> > > > > I would think the memory should still be reserved anyway to make 
> >> > > > > sure
> >> > > > > nothing else is writing over it. And it's in the device tree anyway
> >> > > > > because the driver needs to know where to put framebuffer content. 
> >> > > > > So
> >> > > > > the point I was trying to make is that we can't treat the memory 
> >> > > > > in the
> >> > > > > same way as clocks because it needs to be explicitly managed. 
> >> > > > > Whereas
> >> > > > > clocks don't. The driver is simply too generic to know what to do 
> >> > > > > with
> >> > > > > the clocks.
> >> > > >
> >> > > > You agreed on the fact that the only thing we need to do with the
> >> > > > clocks is claim them. Really, I don't find what's complicated there
> >> > > > (or not generic).
> >> > >
> >> > > That's not what I agreed on. What I said is that the only thing we need
> >> > > to do with the clocks is nothing. They are already in the state that
> >> > > they need to be.
> >> >
> >> > Claim was probably a poor choice of words, but still. We have to keep
> >> > the clock running, and both the solution you've been giving and this
> >> > patch do so in a generic way.
> >> >
> >> > > > > It doesn't know what frequency they should be running at
> >> > > >
> >> > > > We don't care about that. Just like we don't care about which
> >> > > > frequency is the memory bus running at. It will just run at whatever
> >> > > > frequency is appropriate.
> >> > >
> >> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> >> > > already configured the clocks to run at the correct frequencies, and it
> >> > > has made sure that they are enabled.
> >> > >
> >> > > > > or what they're used for
> >> > > >
> >> > > > And we don't care about that either. You're not interested in what
> >> > > > output the framebuffer is setup to use, which is pretty much the same
> >> > > > here, this is the same thing here.
> >> > >
> >> > > That's precisely what I've been saying. The only thing that simplefb
> >> > > cares about is the memory it should be using and the format of the
> >> > > pixels (and how many of them) it writes into that memory. Everything
> >> > > else is assumed to have been set up.
> >> > >
> >> > > Including clocks.
> >> >
> >> > We're really discussing in circles here.
> >> >
> >> > Mike?
> >> >
> >>
> >> -EHIGHLATENCYRESPONSE
> >>
> >> I forgot about this thread. Sorry.
> >>
> >> In an attempt to provide the least helpful answer possible, I will stay
> >> clear of all of the stuff relating to "how simple should simplefb be"
> >> and the related reserved memory discussion.
> >>
> >> A few times in this thread it is stated that we can't prevent unused
> >> clocks from being disabled. That is only partially true.
> >>
> >> The clock framework DOES provide a flag to prevent UNUSED clocks from
> >> being disabled at late_initcall-time by a clock "garbage collector"
> >> mechanism. Maxime and others familiar with the clock framework are aware
> >> of this.
> >>
> >> What the framework doesn't do is to allow for a magic flag in DT, in
> >> platform_data or elsewhere that says, "don't let me get turned off until
> >> the right driver claims me". That would be an external or alternative
> >> method for preventing a clock from being disabled. We have a method for
> >> preventing clocks from being disabled. It is as follows:
> >>
> >> struct clk *my_clk = clk_get(...);
> >> clk_prepare_enable(my_clk);
> >>
> >> That is how it should be done. Period.
> >>
> >> With that said I think that Luc's approach is very sensible. I'm not
> >> sure what purpose in the universe DT is supposed to serve if not for
> >> _this_exact_case_. We have a nice abstracted driver, usable by many
> >> people. The hardware details of how it is hooked up at the board level
> >> can all be hidden behind stable DT bindings that everyone already uses.
> >
> > simplefb doesn't deal at all with hardware details. It simply uses what
> > firmware has set up, which is the only reason why it will work for many
> 
> It doesn't deal with "hardware details for hardware components for which
> no driver is available (yet)". That's why the hardware is still in a usable
> state, after the firmware has set it up.
> 
> Clocks, regulators, PM domains typically have system-wide implications,
> and thus need system-wide drivers (in the absence of such drivers,
> things wo

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

[Geert Uytterhoeven]

Hi Thierry,

(CC linux-pm, as PM is the real reason behind disabling unused clocks)
(CC gregkh and lkml, for driver core)

On Mon, Sep 29, 2014 at 10:06 AM, Thierry Reding
 wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
>> Quoting Maxime Ripard (2014-09-02 02:25:08)
>> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
>> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
>> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
>> > > > > I would think the memory should still be reserved anyway to make sure
>> > > > > nothing else is writing over it. And it's in the device tree anyway
>> > > > > because the driver needs to know where to put framebuffer content. So
>> > > > > the point I was trying to make is that we can't treat the memory in 
>> > > > > the
>> > > > > same way as clocks because it needs to be explicitly managed. Whereas
>> > > > > clocks don't. The driver is simply too generic to know what to do 
>> > > > > with
>> > > > > the clocks.
>> > > >
>> > > > You agreed on the fact that the only thing we need to do with the
>> > > > clocks is claim them. Really, I don't find what's complicated there
>> > > > (or not generic).
>> > >
>> > > That's not what I agreed on. What I said is that the only thing we need
>> > > to do with the clocks is nothing. They are already in the state that
>> > > they need to be.
>> >
>> > Claim was probably a poor choice of words, but still. We have to keep
>> > the clock running, and both the solution you've been giving and this
>> > patch do so in a generic way.
>> >
>> > > > > It doesn't know what frequency they should be running at
>> > > >
>> > > > We don't care about that. Just like we don't care about which
>> > > > frequency is the memory bus running at. It will just run at whatever
>> > > > frequency is appropriate.
>> > >
>> > > Exactly. And you shouldn't have to care about them at all. Firmware has
>> > > already configured the clocks to run at the correct frequencies, and it
>> > > has made sure that they are enabled.
>> > >
>> > > > > or what they're used for
>> > > >
>> > > > And we don't care about that either. You're not interested in what
>> > > > output the framebuffer is setup to use, which is pretty much the same
>> > > > here, this is the same thing here.
>> > >
>> > > That's precisely what I've been saying. The only thing that simplefb
>> > > cares about is the memory it should be using and the format of the
>> > > pixels (and how many of them) it writes into that memory. Everything
>> > > else is assumed to have been set up.
>> > >
>> > > Including clocks.
>> >
>> > We're really discussing in circles here.
>> >
>> > Mike?
>> >
>>
>> -EHIGHLATENCYRESPONSE
>>
>> I forgot about this thread. Sorry.
>>
>> In an attempt to provide the least helpful answer possible, I will stay
>> clear of all of the stuff relating to "how simple should simplefb be"
>> and the related reserved memory discussion.
>>
>> A few times in this thread it is stated that we can't prevent unused
>> clocks from being disabled. That is only partially true.
>>
>> The clock framework DOES provide a flag to prevent UNUSED clocks from
>> being disabled at late_initcall-time by a clock "garbage collector"
>> mechanism. Maxime and others familiar with the clock framework are aware
>> of this.
>>
>> What the framework doesn't do is to allow for a magic flag in DT, in
>> platform_data or elsewhere that says, "don't let me get turned off until
>> the right driver claims me". That would be an external or alternative
>> method for preventing a clock from being disabled. We have a method for
>> preventing clocks from being disabled. It is as follows:
>>
>> struct clk *my_clk = clk_get(...);
>> clk_prepare_enable(my_clk);
>>
>> That is how it should be done. Period.
>>
>> With that said I think that Luc's approach is very sensible. I'm not
>> sure what purpose in the universe DT is supposed to serve if not for
>> _this_exact_case_. We have a nice abstracted driver, usable by many
>> people. The hardware details of how it is hooked up at the board level
>> can all be hidden behind stable DT bindings that everyone already uses.
>
> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many

It doesn't deal with "hardware details for hardware components for which
no driver is available (yet)". That's why the hardware is still in a usable
state, after the firmware has set it up.

Clocks, regulators, PM domains typically have system-wide implications,
and thus need system-wide drivers (in the absence of such drivers,
things would work as-is).

Note that the driver still requests resources (ioremap the frame buffer),
so it needs to know about that tiny piece of hardware detail.

> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simpl

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

[Thierry Reding]

On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:
> Quoting Maxime Ripard (2014-09-02 02:25:08)
> > On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote:
> > > On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote:
> > > > On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote:
> > > > > I would think the memory should still be reserved anyway to make sure
> > > > > nothing else is writing over it. And it's in the device tree anyway
> > > > > because the driver needs to know where to put framebuffer content. So
> > > > > the point I was trying to make is that we can't treat the memory in 
> > > > > the
> > > > > same way as clocks because it needs to be explicitly managed. Whereas
> > > > > clocks don't. The driver is simply too generic to know what to do with
> > > > > the clocks.
> > > > 
> > > > You agreed on the fact that the only thing we need to do with the
> > > > clocks is claim them. Really, I don't find what's complicated there
> > > > (or not generic).
> > > 
> > > That's not what I agreed on. What I said is that the only thing we need
> > > to do with the clocks is nothing. They are already in the state that
> > > they need to be.
> > 
> > Claim was probably a poor choice of words, but still. We have to keep
> > the clock running, and both the solution you've been giving and this
> > patch do so in a generic way.
> > 
> > > > > It doesn't know what frequency they should be running at
> > > > 
> > > > We don't care about that. Just like we don't care about which
> > > > frequency is the memory bus running at. It will just run at whatever
> > > > frequency is appropriate.
> > > 
> > > Exactly. And you shouldn't have to care about them at all. Firmware has
> > > already configured the clocks to run at the correct frequencies, and it
> > > has made sure that they are enabled.
> > > 
> > > > > or what they're used for
> > > > 
> > > > And we don't care about that either. You're not interested in what
> > > > output the framebuffer is setup to use, which is pretty much the same
> > > > here, this is the same thing here.
> > > 
> > > That's precisely what I've been saying. The only thing that simplefb
> > > cares about is the memory it should be using and the format of the
> > > pixels (and how many of them) it writes into that memory. Everything
> > > else is assumed to have been set up.
> > > 
> > > Including clocks.
> > 
> > We're really discussing in circles here.
> > 
> > Mike?
> > 
> 
> -EHIGHLATENCYRESPONSE
> 
> I forgot about this thread. Sorry.
> 
> In an attempt to provide the least helpful answer possible, I will stay
> clear of all of the stuff relating to "how simple should simplefb be"
> and the related reserved memory discussion.
> 
> A few times in this thread it is stated that we can't prevent unused
> clocks from being disabled. That is only partially true.
> 
> The clock framework DOES provide a flag to prevent UNUSED clocks from
> being disabled at late_initcall-time by a clock "garbage collector"
> mechanism. Maxime and others familiar with the clock framework are aware
> of this.
> 
> What the framework doesn't do is to allow for a magic flag in DT, in
> platform_data or elsewhere that says, "don't let me get turned off until
> the right driver claims me". That would be an external or alternative
> method for preventing a clock from being disabled. We have a method for
> preventing clocks from being disabled. It is as follows:
> 
> struct clk *my_clk = clk_get(...);
> clk_prepare_enable(my_clk);
> 
> That is how it should be done. Period.
> 
> With that said I think that Luc's approach is very sensible. I'm not
> sure what purpose in the universe DT is supposed to serve if not for
> _this_exact_case_. We have a nice abstracted driver, usable by many
> people. The hardware details of how it is hooked up at the board level
> can all be hidden behind stable DT bindings that everyone already uses.

simplefb doesn't deal at all with hardware details. It simply uses what
firmware has set up, which is the only reason why it will work for many
people. What is passed in via its device tree node is the minimum amount
of information needed to draw something into the framebuffer. Also note
that the simplefb device tree node is not statically added to a DTS file
but needs to be dynamically generated by firmware at runtime.

If we start extending the binding with board-level details we end up
duplicating the device tree node for the proper video device. Also note
that it won't stop at clocks. Other setups will require regulators to be
listed in this device tree node as well so that they don't get disabled
at late_initcall. And the regulator bindings don't provide a method to
list an arbitrary number of clocks in a single property in the way that
the clocks property works.

There may be also resets involved. Fortunately the reset framework is
minimalistic enough not to care about asserting all unused resets at
late_initcall. And other things like power do