Re: [linux-sunxi] Are there any HDMI-CEC related information for A10/A20 available?

[Chen-Yu Tsai]

Hi,

On Fri, Oct 3, 2014 at 3:29 AM, jonsm...@gmail.com  wrote:
> I
>
> On Thu, Oct 2, 2014 at 1:19 PM, Christian Ege  wrote:
>> During a quick search I had not been able to find any HDMI CEC driver. In
>> the docs available there is only one Register about CEC.
>>
>> I thought about implementation of an driver and libcec support for the A20.
>
> I believe CEC is just I2C on the HDMI connector.
>
> So maybe --- it is one of the I2C devices. Then that bit enables it
> onto the HDMI pin? Just a guess.
>
> EDID works the same way. How is it implemented?

You are referring to DDC. The HDMI block has a separate DDC controller.
IIRC, the DDC pins also have standard TWI muxed on them, so you could
use either one.

But this is entirely irrelevant to the original question.

As Christian stated, the HDMI block does have a register named
HDMI_HDP_CEC. However it does not contain any useful descriptions.
Also the SoC does have a pin for HDMI CEC.

Best ask Allwinner for some help.


ChenYu

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

On Fri, Oct 3, 2014 at 1:14 AM, jonsm...@gmail.com  wrote:
> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 04:41 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede  wrote:
 Hi,

 On 10/02/2014 04:16 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  
> wrote:
>>
>> 
>>
>>> So there are two ways to do this...
>>> 1) modify things like earlyconsole to protect device specific resource
>>> (I think this is a bad idea)
>>
>> Why is this a bad idea? If the bootloader tells us exactly which 
>> resources
>> are needed, then earlyconsole can claim them, and release them on
>> handover to the real display driver.

 Jon, can you please answer this ? I really really want to know why people
 think this is such a bad idea. Understanding why people think this is a bad
 idea is necessary to be able to come up with an alternative solution.
>>>
>>> The list of resources should not be duplicated in the device tree -
>>> once in the simplefb node and again in the real device node.
>>
>> It is not duplicated, the simplefb node will list the clocks used for the
>> mode / output as setup by the firmware, which are often not all clocks
>> which the display engine supports. Where as the real device node will list
>> all clocks the display engine may use.
>>
>>> Device
>>> tree is a hardware description and it is being twisted to solve a
>>> software issue.
>>
>> This is not true, various core devicetree developers have already said
>> that storing other info in the devicetree is fine, and being able to do so
>> is part of the original design.
>>
>>> This problem is not limited to clocks, same problem
>>> exists with regulators. On SGI systems this would exist with entire
>>> bus controllers (but they are x86 based, console is not on the root
>>> bus). This is a very messy problem and will lead to a Frankenstein
>>> sized driver over time.
>>
>> This is a "what if ..." argument, we can discuss potential hypothetical
>> problems all day long, what happens if the sky falls down?
>>
>>> But... I think this is a red herring which is masking the real
>>> problem. The real problem seems to be that there is no window for
>>> loading device specific drivers before the resource clean up phase
>>> happens. That's a real problem -- multi architecture distros are going
>>> to have lots of loadable device specific drivers.
>>
>> As Maxime pointed out to my alternative solution to fixing the clocks
>> problem, this is not strictly a when to do cleanup problem. If another
>> driver uses the same clocks, and does a clk_disable call after probing
>> (because the device is put in low power mode until used by userspace),
>> then the clk will be disabled even without any cleanup running at all.
>>
>> The real problem here is simply that to work the simplefb needs certain
>> resources, just like any other device. And while for any other device
>> simply listing the needed resources is an accepted practice, for simplefb
>> for some reason (which I still do not understand) people all of a sudden
>> see listing resources as a problem.
>
> Because you are creating two different device tree nodes describing a
> single piece of hardware and that's not suppose to happen in a device
> tree.  The accurate description of the hardware is being perverted to
> solve a software problem.
>
> One node describes the hardware in a format to make simplefb happy.
> Another node describes the same hardware in a format to make the
> device specific driver happy.

Stupid question: What about mangling an existing device node to be
simplefb compatible, and writing simplefb to be binding agnostic?

I listed some psuedo-code to do the latter earlier in the thread.

I.e. changing something like this:

vopb: vopb@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
interrupts = ;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru
SRST_LCDC1_DCLK>;
reset-names = "axi", "ahb", "dclk";
iommus = <&vopb_mmu>;
vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
remote-endpoint=<&edp_in_vopb>;
};
vopb_out_hdmi: endpoint@1 {
reg = <1>;
remote-endpoint=<&hdmi_in_vopb>;
};
};
};

into something like this:

vopb: vopb@ff93 {
compatible = "rockchip,rk3288-vop", "simple-framebuffer";
framebuffer {
reg = <0x1d385000 (1600 * 1200 * 2)>;
width = <1600>;
height = <1200>;
stride = <(1600 * 2)>;
format = "r5g6b5";
};
reg = <0xff93 0x19c>;
interrupts = ;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "

Re: [linux-sunxi] Are there any HDMI-CEC related information for A10/A20 available?

[Vladimir Komendantskiy]

I'm working on a generic bit-banging CEC kernel driver for A10s/A20. Those
have only one pin exposed. All control and timing is done in software
according to the CEC addendum in the HDMI 1.4 specification.

This is unlike in NVidia Tegra for example which has a proper hardware CEC
controller.

--Vladimir

On 2 October 2014 20:29, jonsm...@gmail.com  wrote:

> I
>
> On Thu, Oct 2, 2014 at 1:19 PM, Christian Ege  wrote:
> > During a quick search I had not been able to find any HDMI CEC driver. In
> > the docs available there is only one Register about CEC.
> >
> > I thought about implementation of an driver and libcec support for the
> A20.
>
> I believe CEC is just I2C on the HDMI connector.
>
> So maybe --- it is one of the I2C devices. Then that bit enables it
> onto the HDMI pin? Just a guess.
>
> EDID works the same way. How is it implemented?
>
> >
> > Regards,
> > Christian
> >
> > --
> > 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Are there any HDMI-CEC related information for A10/A20 available?

[jonsm...@gmail.com]

I

On Thu, Oct 2, 2014 at 1:19 PM, Christian Ege  wrote:
> During a quick search I had not been able to find any HDMI CEC driver. In
> the docs available there is only one Register about CEC.
>
> I thought about implementation of an driver and libcec support for the A20.

I believe CEC is just I2C on the HDMI connector.

So maybe --- it is one of the I2C devices. Then that bit enables it
onto the HDMI pin? Just a guess.

EDID works the same way. How is it implemented?

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



-- 
Jon Smirl
jonsm...@gmail.com

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

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

[Geert Uytterhoeven]

On Thu, Oct 2, 2014 at 2:22 PM, jonsm...@gmail.com  wrote:
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.

JFYI, the early serial console can also vanish, even very early in the boot
process, before the unused clocks are disabled.
Cfr. http://marc.info/?l=linux-sh&m=141227657322649&w=2

So there's no safety in this world without calling clk_prepare_enable().

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] Re: New board: Merrii M2 (A20)

[Fabiano Kist]

Hi Harry,

For me, work this: 

rmmod sunxi_gmac.ko    and

insmod sunxi_emac.ko

Regards,

Fabiano.

Em quarta-feira, 10 de setembro de 2014 06h20min42s UTC-3, harry escreveu:
>
> Hi Antonio, 
> are you able to get the SATA and ETHERNET working on this board?? can you 
> please send some information on this. i shall be thankful. 
> regards 
> harry 
>
> On Wednesday, March 19, 2014 12:55:03 AM UTC+5:30, abel...@rioservice.com 
> wrote: 
> > Hi Marcos, 
> > 
> > 
> > I get my boards booting with a Linaro and with HDMI output. I think that 
> the problem is in your FEX file configuration. You have configured the 
> output type to LCD and not HDMI. 
> > 
> > 
> > Change the values of the following parameters to the values below, 
> regenerated your script.bin and try again : 
> > 
> > 
> > 
> > [disp_init] 
> > disp_init_enable = 1 
> > disp_mode = 0 
> > screen0_output_type = 3 
> > screen0_output_mode = 4 
> > screen1_output_type = 0 
> > screen1_output_mode = 4 
> > 
> > 
> > Reference : http://linux-sunxi.org/Fex_Guide#disp_init_configuration 
> > 
> > 
> > Now I am working on the ethernet and SATA drivers. 
> > 
> > 
> > Regards, 
> > Antonio Belloni 
> > 
> > 
> > 
> > Em sexta-feira, 14 de fevereiro de 2014 16h00min39s UTC-2, Marcos Cruz 
>  escreveu: 
> > 
> > Hi,  
> > 
> > 
> > 
> > 
> > This is a digital signage board based on A20 SoC, here the website:  
> > http://www.merrii.com/en/detail.asp?id=157 
> > I managed to modify and install the Cubian distribution to function 
> on it but  
> > I'm having problems with its VGA and HDMI outputs (no signal). 
> > The file dmesg_output contains the kernel output. 
> > What is curious about the board is I had to modify script.fex file 
> in order to make  
> > the built in rtl8188etv operational but with the Android that comes 
> pre-installed everything works. 
> > Have anyone any idea about the VGA and HDMI outputs? 
> > 
> > 
> > 
> > 
> > Regards, 
> > 
> > 
> > 
> > 
> > Marcos 
>
>

-- 
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] Are there any HDMI-CEC related information for A10/A20 available?

[Christian Ege]

During a quick search I had not been able to find any HDMI CEC driver. In
the docs available there is only one Register about CEC.

I thought about implementation of an driver and libcec support for the A20.

Regards,
Christian

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

[Stephen Warren]

On 10/02/2014 12:42 AM, Hans de Goede wrote:
...

The whole reason why we want to use simplefb is not just to get things
running until HW specific driver is in place, but also to have early console
output (to help debugging boot problems on devices without a serial console),
in a world where most video drivers are build as loadable modules, so we
won't have video output until quite late into the boot process.


That's a very different use-case than what was originally envisaged.

...

You indicate that you don't have the time for this discussion, and I note that
there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how about
the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
my responsibility (and in my own benefit) to stop this from growing into
a monster ?


I have no issue with you being the maintainer.

I would suggest you track down whoever it was that was involved in the 
original discussion and objected to simplefb performing resource 
management, and get their explicit ack for the addition of 
clocks/regulators/... to it. But, that's just a suggestion.


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

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

[Hans de Goede]

Hi,

On 10/02/2014 05:30 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 11:14 AM, jonsm...@gmail.com  
> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 04:16 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  
>> wrote:
>>>
>>> 
>>>
 So there are two ways to do this...
 1) modify things like earlyconsole to protect device specific resource
 (I think this is a bad idea)
>>>
>>> Why is this a bad idea? If the bootloader tells us exactly which 
>>> resources
>>> are needed, then earlyconsole can claim them, and release them on
>>> handover to the real display driver.
>
> Jon, can you please answer this ? I really really want to know why people
> think this is such a bad idea. Understanding why people think this is a 
> bad
> idea is necessary to be able to come up with an alternative solution.

 The list of resources should not be duplicated in the device tree -
 once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
 Device
 tree is a hardware description and it is being twisted to solve a
 software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
 This problem is not limited to clocks, same problem
 exists with regulators. On SGI systems this would exist with entire
 bus controllers (but they are x86 based, console is not on the root
 bus). This is a very messy problem and will lead to a Frankenstein
 sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
 But... I think this is a red herring which is masking the real
 problem. The real problem seems to be that there is no window for
 loading device specific drivers before the resource clean up phase
 happens. That's a real problem -- multi architecture distros are going
 to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.

That again is a very narrow reading of what is a very generic descriptive
language. Also note that we are already in this situation with simplefb,
all we're advocating is extending the info which is in the simplefb node
so that it is actually usable in a much wider range of scenarios.

>> The accurate description of the hardware is being perverted to
>> solve a software problem.

Again, devicetree is not strictly a hardware description language.

>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.
> 
> But... I think all of this device tree stuff is a red herring and not
> the core problem.

Actually the red herring is people focussing on the init ordering
solution, which as already explained will simply never work, quoting
myself (from above):

>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.

And to repeat myself yet again:

"The real problem here is simply that to work the simplefb needs certain
resources, just like any other device."

So the logical thing to do is to just put the clocks in the node. The only
counter argument I hear yo

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

[Michal Suchanek]

On 2 October 2014 17:30, jonsm...@gmail.com  wrote:
> On Thu, Oct 2, 2014 at 11:14 AM, jonsm...@gmail.com  
> wrote:
>> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:41 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 04:16 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  
>> wrote:
>>>
>>> 
>>>
 So there are two ways to do this...
 1) modify things like earlyconsole to protect device specific resource
 (I think this is a bad idea)
>>>
>>> Why is this a bad idea? If the bootloader tells us exactly which 
>>> resources
>>> are needed, then earlyconsole can claim them, and release them on
>>> handover to the real display driver.
>
> Jon, can you please answer this ? I really really want to know why people
> think this is such a bad idea. Understanding why people think this is a 
> bad
> idea is necessary to be able to come up with an alternative solution.

 The list of resources should not be duplicated in the device tree -
 once in the simplefb node and again in the real device node.
>>>
>>> It is not duplicated, the simplefb node will list the clocks used for the
>>> mode / output as setup by the firmware, which are often not all clocks
>>> which the display engine supports. Where as the real device node will list
>>> all clocks the display engine may use.
>>>
 Device
 tree is a hardware description and it is being twisted to solve a
 software issue.
>>>
>>> This is not true, various core devicetree developers have already said
>>> that storing other info in the devicetree is fine, and being able to do so
>>> is part of the original design.
>>>
 This problem is not limited to clocks, same problem
 exists with regulators. On SGI systems this would exist with entire
 bus controllers (but they are x86 based, console is not on the root
 bus). This is a very messy problem and will lead to a Frankenstein
 sized driver over time.
>>>
>>> This is a "what if ..." argument, we can discuss potential hypothetical
>>> problems all day long, what happens if the sky falls down?
>>>
 But... I think this is a red herring which is masking the real
 problem. The real problem seems to be that there is no window for
 loading device specific drivers before the resource clean up phase
 happens. That's a real problem -- multi architecture distros are going
 to have lots of loadable device specific drivers.
>>>
>>> As Maxime pointed out to my alternative solution to fixing the clocks
>>> problem, this is not strictly a when to do cleanup problem. If another
>>> driver uses the same clocks, and does a clk_disable call after probing
>>> (because the device is put in low power mode until used by userspace),
>>> then the clk will be disabled even without any cleanup running at all.
>>>
>>> The real problem here is simply that to work the simplefb needs certain
>>> resources, just like any other device. And while for any other device
>>> simply listing the needed resources is an accepted practice, for simplefb
>>> for some reason (which I still do not understand) people all of a sudden
>>> see listing resources as a problem.
>>
>> Because you are creating two different device tree nodes describing a
>> single piece of hardware and that's not suppose to happen in a device
>> tree.  The accurate description of the hardware is being perverted to
>> solve a software problem.
>>
>> One node describes the hardware in a format to make simplefb happy.
>> Another node describes the same hardware in a format to make the
>> device specific driver happy.

No.

one node describes the state in which the hardware was left by u-boot
and other node describes the display hardware in full.

Obviously, this will overlap but is not duplication.

Or as pointed out the simplefb node is not hardware description but
'other information' which is part of the DT design. If your system
does not use simplefb it can be ignored with no ill side effect (once
the part with claiming memory for simplefb cleanly is resolved).

Did we not discuss that several times already?

>
> But... I think all of this device tree stuff is a red herring and not
> the core problem.
>
> Core problem.
>
> Bios sets stuff up
> Built-in drivers initialize
> Bios settings get cleaned up (display goes blank)
> Loadable drivers initialize (display comes back)
>
> In multi-architecture kernels almost all of the drivers are loadable.
> We need to figure out how to change the order
>
> Bios sets stuff up
> Built-in drivers initialize
> Loadable drivers initialize
> Bios settings get cleaned up
>
> Maybe the Bios cleanup turns into a small app you place at the end of
> your init scripts. It's just a power saving cleanup and shouldn't be
> causing this much trouble.

No. You need to do cleanup during driver lo

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 11:14 AM, jonsm...@gmail.com  wrote:
> On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 04:41 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede  wrote:
 Hi,

 On 10/02/2014 04:16 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  
> wrote:
>>
>> 
>>
>>> So there are two ways to do this...
>>> 1) modify things like earlyconsole to protect device specific resource
>>> (I think this is a bad idea)
>>
>> Why is this a bad idea? If the bootloader tells us exactly which 
>> resources
>> are needed, then earlyconsole can claim them, and release them on
>> handover to the real display driver.

 Jon, can you please answer this ? I really really want to know why people
 think this is such a bad idea. Understanding why people think this is a bad
 idea is necessary to be able to come up with an alternative solution.
>>>
>>> The list of resources should not be duplicated in the device tree -
>>> once in the simplefb node and again in the real device node.
>>
>> It is not duplicated, the simplefb node will list the clocks used for the
>> mode / output as setup by the firmware, which are often not all clocks
>> which the display engine supports. Where as the real device node will list
>> all clocks the display engine may use.
>>
>>> Device
>>> tree is a hardware description and it is being twisted to solve a
>>> software issue.
>>
>> This is not true, various core devicetree developers have already said
>> that storing other info in the devicetree is fine, and being able to do so
>> is part of the original design.
>>
>>> This problem is not limited to clocks, same problem
>>> exists with regulators. On SGI systems this would exist with entire
>>> bus controllers (but they are x86 based, console is not on the root
>>> bus). This is a very messy problem and will lead to a Frankenstein
>>> sized driver over time.
>>
>> This is a "what if ..." argument, we can discuss potential hypothetical
>> problems all day long, what happens if the sky falls down?
>>
>>> But... I think this is a red herring which is masking the real
>>> problem. The real problem seems to be that there is no window for
>>> loading device specific drivers before the resource clean up phase
>>> happens. That's a real problem -- multi architecture distros are going
>>> to have lots of loadable device specific drivers.
>>
>> As Maxime pointed out to my alternative solution to fixing the clocks
>> problem, this is not strictly a when to do cleanup problem. If another
>> driver uses the same clocks, and does a clk_disable call after probing
>> (because the device is put in low power mode until used by userspace),
>> then the clk will be disabled even without any cleanup running at all.
>>
>> The real problem here is simply that to work the simplefb needs certain
>> resources, just like any other device. And while for any other device
>> simply listing the needed resources is an accepted practice, for simplefb
>> for some reason (which I still do not understand) people all of a sudden
>> see listing resources as a problem.
>
> Because you are creating two different device tree nodes describing a
> single piece of hardware and that's not suppose to happen in a device
> tree.  The accurate description of the hardware is being perverted to
> solve a software problem.
>
> One node describes the hardware in a format to make simplefb happy.
> Another node describes the same hardware in a format to make the
> device specific driver happy.

But... I think all of this device tree stuff is a red herring and not
the core problem.

Core problem.

Bios sets stuff up
Built-in drivers initialize
Bios settings get cleaned up (display goes blank)
Loadable drivers initialize (display comes back)

In multi-architecture kernels almost all of the drivers are loadable.
We need to figure out how to change the order

Bios sets stuff up
Built-in drivers initialize
Loadable drivers initialize
Bios settings get cleaned up

Maybe the Bios cleanup turns into a small app you place at the end of
your init scripts. It's just a power saving cleanup and shouldn't be
causing this much trouble.

I don't think leaving the order as is and using the device tree to
construct a big list of exceptions to the clean up process is the
right approach.

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



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

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 10:50 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 04:41 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/02/2014 04:16 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  wrote:
>
> 
>
>> So there are two ways to do this...
>> 1) modify things like earlyconsole to protect device specific resource
>> (I think this is a bad idea)
>
> Why is this a bad idea? If the bootloader tells us exactly which resources
> are needed, then earlyconsole can claim them, and release them on
> handover to the real display driver.
>>>
>>> Jon, can you please answer this ? I really really want to know why people
>>> think this is such a bad idea. Understanding why people think this is a bad
>>> idea is necessary to be able to come up with an alternative solution.
>>
>> The list of resources should not be duplicated in the device tree -
>> once in the simplefb node and again in the real device node.
>
> It is not duplicated, the simplefb node will list the clocks used for the
> mode / output as setup by the firmware, which are often not all clocks
> which the display engine supports. Where as the real device node will list
> all clocks the display engine may use.
>
>> Device
>> tree is a hardware description and it is being twisted to solve a
>> software issue.
>
> This is not true, various core devicetree developers have already said
> that storing other info in the devicetree is fine, and being able to do so
> is part of the original design.
>
>> This problem is not limited to clocks, same problem
>> exists with regulators. On SGI systems this would exist with entire
>> bus controllers (but they are x86 based, console is not on the root
>> bus). This is a very messy problem and will lead to a Frankenstein
>> sized driver over time.
>
> This is a "what if ..." argument, we can discuss potential hypothetical
> problems all day long, what happens if the sky falls down?
>
>> But... I think this is a red herring which is masking the real
>> problem. The real problem seems to be that there is no window for
>> loading device specific drivers before the resource clean up phase
>> happens. That's a real problem -- multi architecture distros are going
>> to have lots of loadable device specific drivers.
>
> As Maxime pointed out to my alternative solution to fixing the clocks
> problem, this is not strictly a when to do cleanup problem. If another
> driver uses the same clocks, and does a clk_disable call after probing
> (because the device is put in low power mode until used by userspace),
> then the clk will be disabled even without any cleanup running at all.
>
> The real problem here is simply that to work the simplefb needs certain
> resources, just like any other device. And while for any other device
> simply listing the needed resources is an accepted practice, for simplefb
> for some reason (which I still do not understand) people all of a sudden
> see listing resources as a problem.

Because you are creating two different device tree nodes describing a
single piece of hardware and that's not suppose to happen in a device
tree.  The accurate description of the hardware is being perverted to
solve a software problem.

One node describes the hardware in a format to make simplefb happy.
Another node describes the same hardware in a format to make the
device specific driver happy.


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



-- 
Jon Smirl
jonsm...@gmail.com

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

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

[Hans de Goede]

Hi,

On 10/02/2014 04:41 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 04:16 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  wrote:



> So there are two ways to do this...
> 1) modify things like earlyconsole to protect device specific resource
> (I think this is a bad idea)

 Why is this a bad idea? If the bootloader tells us exactly which resources
 are needed, then earlyconsole can claim them, and release them on
 handover to the real display driver.
>>
>> Jon, can you please answer this ? I really really want to know why people
>> think this is such a bad idea. Understanding why people think this is a bad
>> idea is necessary to be able to come up with an alternative solution.
> 
> The list of resources should not be duplicated in the device tree -
> once in the simplefb node and again in the real device node.

It is not duplicated, the simplefb node will list the clocks used for the
mode / output as setup by the firmware, which are often not all clocks
which the display engine supports. Where as the real device node will list
all clocks the display engine may use.

> Device
> tree is a hardware description and it is being twisted to solve a
> software issue.

This is not true, various core devicetree developers have already said
that storing other info in the devicetree is fine, and being able to do so
is part of the original design.

> This problem is not limited to clocks, same problem
> exists with regulators. On SGI systems this would exist with entire
> bus controllers (but they are x86 based, console is not on the root
> bus). This is a very messy problem and will lead to a Frankenstein
> sized driver over time.

This is a "what if ..." argument, we can discuss potential hypothetical
problems all day long, what happens if the sky falls down?

> But... I think this is a red herring which is masking the real
> problem. The real problem seems to be that there is no window for
> loading device specific drivers before the resource clean up phase
> happens. That's a real problem -- multi architecture distros are going
> to have lots of loadable device specific drivers.

As Maxime pointed out to my alternative solution to fixing the clocks
problem, this is not strictly a when to do cleanup problem. If another
driver uses the same clocks, and does a clk_disable call after probing
(because the device is put in low power mode until used by userspace),
then the clk will be disabled even without any cleanup running at all.

The real problem here is simply that to work the simplefb needs certain
resources, just like any other device. And while for any other device
simply listing the needed resources is an accepted practice, for simplefb
for some reason (which I still do not understand) people all of a sudden
see listing resources as a problem.

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 10:21 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 04:16 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/02/2014 03:40 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 03:27 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  
>> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  
 wrote:
> Hi,
>
> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  
>> wrote:
>>> Hi,
>>>
>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
 On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede 
>  wrote:
 ...
>> We've been over all this again and again and again.
>>
>> RGH!
>>
>> All solutions provided sofar are both tons more complicated, 
>> then the
>> simple solution of simply having the simplefb dt node declare 
>> which
>> clocks it needs. And to make things worse all of them sofar have
>> unresolved issues (due to their complexity mostly).
>>
>> With the clocks in the simplefb node, then all a real driver has 
>> to do,
>> is claim those same clocks before unregistering the simplefb 
>> driver,
>> and everything will just work.
>>
>> Yet we've been discussing this for months, all because of some
>> vague worries from Thierry, and *only* from Thierry that this 
>> will
>> make simplefb less generic / not abstract enough, while a simple
>> generic clocks property is about as generic as things come.

 Note: I haven't been following this thread, and really don't have 
 the time to get involved, but I did want to point out one thing:

 As I think I mentioned very early on in this thread, one of the 
 big concerns when simplefb was merged was that it would slowly 
 grow and become a monster. As such, a condition of merging it was 
 that it would not grow features like resource management at all. 
 That means no clock/regulator/... support. It's intended as a 
 simple stop-gap between early platform bringup and whenever a real 
 driver exists for the HW. If you need resource management, write a 
 HW-specific driver. The list archives presumably have a record of 
 the discussion, but I don't know the links off the top of my head. 
 If nobody
 other than Thierry is objecting, presumably the people who 
 originally objected simply haven't noticed this patch/thread. I 
 suppose it's possible they changed their mind.

 BTW, there's no reason that the simplefb code couldn't be 
 refactored out into a support library that's used by both the 
 simplefb we currently have and any new HW-specific driver. It's 
 just that the simplefb binding and driver shouldn't grow.
>>>
>>> The whole reason why we want to use simplefb is not just to get 
>>> things
>>> running until HW specific driver is in place, but also to have 
>>> early console
>>> output (to help debugging boot problems on devices without a serial 
>>> console),
>>> in a world where most video drivers are build as loadable modules, 
>>> so we
>>> won't have video output until quite late into the boot process.
>>
>> You need both.
>>
>> 1) temporary early boot console -- this is nothing but an address in
>> RAM and the x/y layout. The character set from framebuffer is built
>> into the kernel.  The parallel to this is early-printk and how it 
>> uses
>> the UARTs without interrupts. This console vaporizes late in the boot
>> process -- the same thing happens with the early printk UART driver.
>> EARLYPRINTK on the command line enables this.
>>
>> 2) a device specific driver -- this sits on initrd and it loaded as
>> soon as possible. The same thing happens with the real UART driver 
>> for
>> the console. CONSOLE= on the command line causes the transition. 
>> There
>> is an API in the kernel to do this transition, I believe it is called
>> set_console() but it's been a while.
>
>

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

[Hans de Goede]

Hi,

On 10/02/2014 04:18 PM, Maxime Ripard wrote:
> On Thu, Oct 02, 2014 at 04:08:52PM +0200, Hans de Goede wrote:
>>> 2) delay the clock/regulator cleanup until after there is a fixed
>>> window for device specific drivers to load in. Loading from initrd is
>>> a fixed window.
>>
>> As I already explained by example in another mail, this won't work:
>>
>> "delaying over the initrd is not helpful. Not having the real driver
>> load for whatever reasons, is not necessarily a boot blocking event,
>> and if it us just missing will not lead to any error messages.
>>
>> So the boot will continue normally with a black screen, and things are
>> still impossible to debug."
> 
> Plus:
> 
> 1) you might not have an initrd, which doesn't change a thing: your
> clock get disabled before you can load your driver
> 
> 2) you might not have a rootfs, and no driver to load, which would
> leave the clock enabled forever.
> 
>> We've been down the whole delay till $random point in time thing in the
>> past with storage enumeration, where you need to wait for say all members
>> of a raid set to show up. The lesson learned from that is that you should
>> not wait $random time / event, but wait for the actual storage device to
>> show up.
>>
>> And this is just like that, we need to wait for the actual display driver
>> to have loaded and taken over before "cleaning up" the clocks used by
>> the display engine.
>>
>> I guess we could just delay all clock cleanup until then, not really
>> pretty, and I still prefer to just list the clocks in the simplefb
>> dtnode, but if this version would be acceptable to all involved, I can
>> live with it.
>>
>> Mike, would a patch adding 2 calls like these to the clock core be
>> acceptable ?  :
>>
>> clk_block_disable_unused()
>> clk_unblock_disable_unused()
> 
> Thierry actually already made such a patch somewhere in this
> thread. The thing is that it should also block clk_disable (and all
> the potential users of clk_disable: clk_set_rate, clk_set_parent,
> etc.) from actually disabling them. Otherwise, you might still end up
> with your clock disabled.

A valid point, which brings us back to simply adding the clocks to the
dt node really being both the simplest solution, as well as the only
solution without any pitfalls.

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

[Hans de Goede]

Hi,

On 10/02/2014 04:16 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 03:40 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede  wrote:
 Hi,

 On 10/02/2014 03:27 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  
>>> wrote:
 Hi,

 On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  
> wrote:
>> Hi,
>>
>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
 On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede 
  wrote:
>>> ...
> We've been over all this again and again and again.
>
> RGH!
>
> All solutions provided sofar are both tons more complicated, then 
> the
> simple solution of simply having the simplefb dt node declare 
> which
> clocks it needs. And to make things worse all of them sofar have
> unresolved issues (due to their complexity mostly).
>
> With the clocks in the simplefb node, then all a real driver has 
> to do,
> is claim those same clocks before unregistering the simplefb 
> driver,
> and everything will just work.
>
> Yet we've been discussing this for months, all because of some
> vague worries from Thierry, and *only* from Thierry that this will
> make simplefb less generic / not abstract enough, while a simple
> generic clocks property is about as generic as things come.
>>>
>>> Note: I haven't been following this thread, and really don't have 
>>> the time to get involved, but I did want to point out one thing:
>>>
>>> As I think I mentioned very early on in this thread, one of the big 
>>> concerns when simplefb was merged was that it would slowly grow and 
>>> become a monster. As such, a condition of merging it was that it 
>>> would not grow features like resource management at all. That means 
>>> no clock/regulator/... support. It's intended as a simple stop-gap 
>>> between early platform bringup and whenever a real driver exists 
>>> for the HW. If you need resource management, write a HW-specific 
>>> driver. The list archives presumably have a record of the 
>>> discussion, but I don't know the links off the top of my head. If 
>>> nobody
>>> other than Thierry is objecting, presumably the people who 
>>> originally objected simply haven't noticed this patch/thread. I 
>>> suppose it's possible they changed their mind.
>>>
>>> BTW, there's no reason that the simplefb code couldn't be 
>>> refactored out into a support library that's used by both the 
>>> simplefb we currently have and any new HW-specific driver. It's 
>>> just that the simplefb binding and driver shouldn't grow.
>>
>> The whole reason why we want to use simplefb is not just to get 
>> things
>> running until HW specific driver is in place, but also to have early 
>> console
>> output (to help debugging boot problems on devices without a serial 
>> console),
>> in a world where most video drivers are build as loadable modules, 
>> so we
>> won't have video output until quite late into the boot process.
>
> You need both.
>
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.
>
> 2) a device specific driver -- this sits on initrd and it loaded as
> soon as possible. The same thing happens with the real UART driver for
> the console. CONSOLE= on the command line causes the transition. There
> is an API in the kernel to do this transition, I believe it is called
> set_console() but it's been a while.

 Eventually we need both, yes. But 1) should stay working until 2) 
 loads,
 not until some phase of the bootup is completed, but simply until 2) 
 loads.
>>>
>>> No, that is w

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

[Maxime Ripard]

On Thu, Oct 02, 2014 at 04:08:52PM +0200, Hans de Goede wrote:
> > 2) delay the clock/regulator cleanup until after there is a fixed
> > window for device specific drivers to load in. Loading from initrd is
> > a fixed window.
> 
> As I already explained by example in another mail, this won't work:
> 
> "delaying over the initrd is not helpful. Not having the real driver
> load for whatever reasons, is not necessarily a boot blocking event,
> and if it us just missing will not lead to any error messages.
> 
> So the boot will continue normally with a black screen, and things are
> still impossible to debug."

Plus:

1) you might not have an initrd, which doesn't change a thing: your
clock get disabled before you can load your driver

2) you might not have a rootfs, and no driver to load, which would
leave the clock enabled forever.

> We've been down the whole delay till $random point in time thing in the
> past with storage enumeration, where you need to wait for say all members
> of a raid set to show up. The lesson learned from that is that you should
> not wait $random time / event, but wait for the actual storage device to
> show up.
> 
> And this is just like that, we need to wait for the actual display driver
> to have loaded and taken over before "cleaning up" the clocks used by
> the display engine.
> 
> I guess we could just delay all clock cleanup until then, not really
> pretty, and I still prefer to just list the clocks in the simplefb
> dtnode, but if this version would be acceptable to all involved, I can
> live with it.
> 
> Mike, would a patch adding 2 calls like these to the clock core be
> acceptable ?  :
> 
> clk_block_disable_unused()
> clk_unblock_disable_unused()

Thierry actually already made such a patch somewhere in this
thread. The thing is that it should also block clk_disable (and all
the potential users of clk_disable: clk_set_rate, clk_set_parent,
etc.) from actually disabling them. Otherwise, you might still end up
with your clock disabled.

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 2 October 2014 15:40, jonsm...@gmail.com  wrote:
> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 03:27 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  wrote:
 Hi,

 On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  
>>> wrote:
 Hi,

 On 10/01/2014 08:12 PM, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
>> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> RGH!
>>>
>>> All solutions provided sofar are both tons more complicated, then 
>>> the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to 
>>> do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
>
> Note: I haven't been following this thread, and really don't have the 
> time to get involved, but I did want to point out one thing:
>
> As I think I mentioned very early on in this thread, one of the big 
> concerns when simplefb was merged was that it would slowly grow and 
> become a monster. As such, a condition of merging it was that it 
> would not grow features like resource management at all. That means 
> no clock/regulator/... support. It's intended as a simple stop-gap 
> between early platform bringup and whenever a real driver exists for 
> the HW. If you need resource management, write a HW-specific driver. 
> The list archives presumably have a record of the discussion, but I 
> don't know the links off the top of my head. If nobody
> other than Thierry is objecting, presumably the people who originally 
> objected simply haven't noticed this patch/thread. I suppose it's 
> possible they changed their mind.
>
> BTW, there's no reason that the simplefb code couldn't be refactored 
> out into a support library that's used by both the simplefb we 
> currently have and any new HW-specific driver. It's just that the 
> simplefb binding and driver shouldn't grow.

 The whole reason why we want to use simplefb is not just to get things
 running until HW specific driver is in place, but also to have early 
 console
 output (to help debugging boot problems on devices without a serial 
 console),
 in a world where most video drivers are build as loadable modules, so 
 we
 won't have video output until quite late into the boot process.
>>>
>>> You need both.
>>>
>>> 1) temporary early boot console -- this is nothing but an address in
>>> RAM and the x/y layout. The character set from framebuffer is built
>>> into the kernel.  The parallel to this is early-printk and how it uses
>>> the UARTs without interrupts. This console vaporizes late in the boot
>>> process -- the same thing happens with the early printk UART driver.
>>> EARLYPRINTK on the command line enables this.
>>>
>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>> soon as possible. The same thing happens with the real UART driver for
>>> the console. CONSOLE= on the command line causes the transition. There
>>> is an API in the kernel to do this transition, I believe it is called
>>> set_console() but it's been a while.
>>
>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>> not until some phase of the bootup is completed, but simply until 2) 
>> loads.
>
> No, that is where you get into trouble. The device specific driver has
> to go onto initrd where it can be loaded as early in the boot process
> as possible.

 This is an argument in the "you cannot do that" / "your use case is not 
 valid"
 category, IOW this is not a technical argument. You say I cannot do that I
 say I can, deadlock.
>>>
>>> It is certainly p

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 10:08 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 03:40 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/02/2014 03:27 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  
>> wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  
 wrote:
> Hi,
>
> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
>>> wrote:
>> ...
 We've been over all this again and again and again.

 RGH!

 All solutions provided sofar are both tons more complicated, then 
 the
 simple solution of simply having the simplefb dt node declare which
 clocks it needs. And to make things worse all of them sofar have
 unresolved issues (due to their complexity mostly).

 With the clocks in the simplefb node, then all a real driver has 
 to do,
 is claim those same clocks before unregistering the simplefb 
 driver,
 and everything will just work.

 Yet we've been discussing this for months, all because of some
 vague worries from Thierry, and *only* from Thierry that this will
 make simplefb less generic / not abstract enough, while a simple
 generic clocks property is about as generic as things come.
>>
>> Note: I haven't been following this thread, and really don't have 
>> the time to get involved, but I did want to point out one thing:
>>
>> As I think I mentioned very early on in this thread, one of the big 
>> concerns when simplefb was merged was that it would slowly grow and 
>> become a monster. As such, a condition of merging it was that it 
>> would not grow features like resource management at all. That means 
>> no clock/regulator/... support. It's intended as a simple stop-gap 
>> between early platform bringup and whenever a real driver exists for 
>> the HW. If you need resource management, write a HW-specific driver. 
>> The list archives presumably have a record of the discussion, but I 
>> don't know the links off the top of my head. If nobody
>> other than Thierry is objecting, presumably the people who 
>> originally objected simply haven't noticed this patch/thread. I 
>> suppose it's possible they changed their mind.
>>
>> BTW, there's no reason that the simplefb code couldn't be refactored 
>> out into a support library that's used by both the simplefb we 
>> currently have and any new HW-specific driver. It's just that the 
>> simplefb binding and driver shouldn't grow.
>
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early 
> console
> output (to help debugging boot problems on devices without a serial 
> console),
> in a world where most video drivers are build as loadable modules, so 
> we
> won't have video output until quite late into the boot process.

 You need both.

 1) temporary early boot console -- this is nothing but an address in
 RAM and the x/y layout. The character set from framebuffer is built
 into the kernel.  The parallel to this is early-printk and how it uses
 the UARTs without interrupts. This console vaporizes late in the boot
 process -- the same thing happens with the early printk UART driver.
 EARLYPRINTK on the command line enables this.

 2) a device specific driver -- this sits on initrd and it loaded as
 soon as possible. The same thing happens with the real UART driver for
 the console. CONSOLE= on the command line causes the transition. There
 is an API in the kernel to do this transition, I believe it is called
 set_console() but it's been a while.
>>>
>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>> not until some phase of the bootup is completed, but simply until 2) 
>>> loads.
>>
>> No, that is where you get into trouble. The device specific driver has
>> to go onto initrd where it can be loaded as early in the boot process
>> as possible.
>
> This is an argument in the "you cann

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

[Hans de Goede]

Hi,

On 10/02/2014 03:40 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 03:27 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  wrote:
 Hi,

 On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  
>>> wrote:
 Hi,

 On 10/01/2014 08:12 PM, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
>> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> RGH!
>>>
>>> All solutions provided sofar are both tons more complicated, then 
>>> the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to 
>>> do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
>
> Note: I haven't been following this thread, and really don't have the 
> time to get involved, but I did want to point out one thing:
>
> As I think I mentioned very early on in this thread, one of the big 
> concerns when simplefb was merged was that it would slowly grow and 
> become a monster. As such, a condition of merging it was that it 
> would not grow features like resource management at all. That means 
> no clock/regulator/... support. It's intended as a simple stop-gap 
> between early platform bringup and whenever a real driver exists for 
> the HW. If you need resource management, write a HW-specific driver. 
> The list archives presumably have a record of the discussion, but I 
> don't know the links off the top of my head. If nobody
> other than Thierry is objecting, presumably the people who originally 
> objected simply haven't noticed this patch/thread. I suppose it's 
> possible they changed their mind.
>
> BTW, there's no reason that the simplefb code couldn't be refactored 
> out into a support library that's used by both the simplefb we 
> currently have and any new HW-specific driver. It's just that the 
> simplefb binding and driver shouldn't grow.

 The whole reason why we want to use simplefb is not just to get things
 running until HW specific driver is in place, but also to have early 
 console
 output (to help debugging boot problems on devices without a serial 
 console),
 in a world where most video drivers are build as loadable modules, so 
 we
 won't have video output until quite late into the boot process.
>>>
>>> You need both.
>>>
>>> 1) temporary early boot console -- this is nothing but an address in
>>> RAM and the x/y layout. The character set from framebuffer is built
>>> into the kernel.  The parallel to this is early-printk and how it uses
>>> the UARTs without interrupts. This console vaporizes late in the boot
>>> process -- the same thing happens with the early printk UART driver.
>>> EARLYPRINTK on the command line enables this.
>>>
>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>> soon as possible. The same thing happens with the real UART driver for
>>> the console. CONSOLE= on the command line causes the transition. There
>>> is an API in the kernel to do this transition, I believe it is called
>>> set_console() but it's been a while.
>>
>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>> not until some phase of the bootup is completed, but simply until 2) 
>> loads.
>
> No, that is where you get into trouble. The device specific driver has
> to go onto initrd where it can be loaded as early in the boot process
> as possible.

 This is an argument in the "you cannot do that" / "your use case is not 
 valid"
 category, IOW this is not a technical argument. You say I cannot do that I
 say I can, deadlock.
>>>
>>> It is certainl

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

[Michal Suchanek]

On 2 October 2014 15:27, jonsm...@gmail.com  wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
 Hi,

 On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
>
> You need both.
>
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.
>
> 2) a device specific driver -- this sits on initrd and it loaded as
> soon as possible. The same thing happens with the real UART driver for
> the console. CONSOLE= on the command line causes the transition. There
> is an API in the kernel to do this transition, I believe it is called
> set_console() but it's been a while.

 Eventually we need both, yes. But 1) should stay working until 2) loads,
 not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>
>> This is an argument in the "you cannot do that" / "your use case is not 
>> valid"
>> category, IOW this is not a technical argument. You say I cannot do that I
>> say I can, deadlock.
>
> It is certainly possible to extend an earlyframebuffer to be able to
> run as a user space console. It is just going to turn into a
> Frankenmonster driver with piles of device specific, special case code
> in it.

What is device specific about code that reads a list of clocks and
just asks tells kernel it uses them all?

That's been discussed to death in this thread already.

>
> I think that device specific code belongs in a device specific driver
> and earlyframebuffer should handoff to it as soon as possible.

Even it that case it needs to tell the kernel it needs the clocks so
that they are not shut of until that handoff happens.

>
>>
>> I've already explained that we not only can do that (we already have working
>> code proving that), but also that this is something which we absolutely need:
>>
 One example why this is necessary is e.g. to debug things where the problem
 is that the right module is not included in the initrd.
>
> A generic earlyframebuffer would show this error.
>
> Just use earlyprintk as a guideline, if earlyprintk shows the error
> earlyframebuffer would also show it.
>

It does not. It hands off to an uart driver built into the kernel. The
handoff is broken on sunxi and the earlyprintk continues to work
indefinitely replicating all kernel messages twice on the serial
console unless something happens to reconfigure the uart used for
earlyprink later on. When that does happen the early console can fail
very early, even way before the time you would load an initrd. It just
happens to work most of the time because when you use earlyprintk most
of the time you also use serial console with the same parameters on
the same pins.

Thanks

Michal

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

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 9:46 AM, Geert Uytterhoeven  wrote:
> On Thu, Oct 2, 2014 at 3:34 PM, jonsm...@gmail.com  wrote:
>> Does the clock and regulator cleanup happen before drivers can load
>> off from initrd? I didn't think it did but I might be wrong.
>
> Yes
>
> drivers/base/power/domain.c:late_initcall(genpd_poweroff_unused);
> drivers/clk/clk.c:late_initcall_sync(clk_disable_unused);
> drivers/regulator/core.c:late_initcall_sync(regulator_init_complete);

I think this is the basic problem, we need to open a window where
drivers can be loaded before the clock/regulator clean up happens.
That window needs to be fixed length (ie Ramdisk based loading).

This is a core problem in a multi-architecture kernel, we need to get
the device specific drivers loaded before this clean up happens.



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



-- 
Jon Smirl
jonsm...@gmail.com

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

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

[Geert Uytterhoeven]

On Thu, Oct 2, 2014 at 3:34 PM, jonsm...@gmail.com  wrote:
> Does the clock and regulator cleanup happen before drivers can load
> off from initrd? I didn't think it did but I might be wrong.

Yes

drivers/base/power/domain.c:late_initcall(genpd_poweroff_unused);
drivers/clk/clk.c:late_initcall_sync(clk_disable_unused);
drivers/regulator/core.c:late_initcall_sync(regulator_init_complete);

Gr{oetje,eeting}s,

Geert

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

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

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

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 9:40 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 03:34 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek  wrote:
>>> On 2 October 2014 14:56, jonsm...@gmail.com  wrote:
 On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  
>> wrote:
>>> Hi,
>>>
>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
 On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
> wrote:
 ...
>> We've been over all this again and again and again.
>>
>> RGH!
>>
>> All solutions provided sofar are both tons more complicated, then the
>> simple solution of simply having the simplefb dt node declare which
>> clocks it needs. And to make things worse all of them sofar have
>> unresolved issues (due to their complexity mostly).
>>
>> With the clocks in the simplefb node, then all a real driver has to 
>> do,
>> is claim those same clocks before unregistering the simplefb driver,
>> and everything will just work.
>>
>> Yet we've been discussing this for months, all because of some
>> vague worries from Thierry, and *only* from Thierry that this will
>> make simplefb less generic / not abstract enough, while a simple
>> generic clocks property is about as generic as things come.

 Note: I haven't been following this thread, and really don't have the 
 time to get involved, but I did want to point out one thing:

 As I think I mentioned very early on in this thread, one of the big 
 concerns when simplefb was merged was that it would slowly grow and 
 become a monster. As such, a condition of merging it was that it would 
 not grow features like resource management at all. That means no 
 clock/regulator/... support. It's intended as a simple stop-gap 
 between early platform bringup and whenever a real driver exists for 
 the HW. If you need resource management, write a HW-specific driver. 
 The list archives presumably have a record of the discussion, but I 
 don't know the links off the top of my head. If nobody
 other than Thierry is objecting, presumably the people who originally 
 objected simply haven't noticed this patch/thread. I suppose it's 
 possible they changed their mind.

 BTW, there's no reason that the simplefb code couldn't be refactored 
 out into a support library that's used by both the simplefb we 
 currently have and any new HW-specific driver. It's just that the 
 simplefb binding and driver shouldn't grow.
>>>
>>> The whole reason why we want to use simplefb is not just to get things
>>> running until HW specific driver is in place, but also to have early 
>>> console
>>> output (to help debugging boot problems on devices without a serial 
>>> console),
>>> in a world where most video drivers are build as loadable modules, so we
>>> won't have video output until quite late into the boot process.
>>
>> You need both.
>>
>> 1) temporary early boot console -- this is nothing but an address in
>> RAM and the x/y layout. The character set from framebuffer is built
>> into the kernel.  The parallel to this is early-printk and how it uses
>> the UARTs without interrupts. This console vaporizes late in the boot
>> process -- the same thing happens with the early printk UART driver.
>> EARLYPRINTK on the command line enables this.
>>
>> 2) a device specific driver -- this sits on initrd and it loaded as
>> soon as possible. The same thing happens with the real UART driver for
>> the console. CONSOLE= on the command line causes the transition. There
>> is an API in the kernel to do this transition, I believe it is called
>> set_console() but it's been a while.
>
> Eventually we need both, yes. But 1) should stay working until 2) loads,
> not until some phase of the bootup is completed, but simply until 2) 
> loads.

 No, that is where you get into trouble. The device specific driver has
 to go onto initrd where it can be loaded as early in the boot process
 as possible.

 Trying to indefinitely extend the life of the earlyprintk or
 earlyframeuffer is what causes problems.  Doing that forces you to
 basically turn them into device specific drivers which do things like
 claiming device specific resources and gaining device specific
 dependency knowledge, things that shouldn't be in earlyframebuffer.

>>>
>>> No. When initrd is running bo

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 9:33 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 03:27 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  
>> wrote:
>>> Hi,
>>>
>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
 On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
> wrote:
 ...
>> We've been over all this again and again and again.
>>
>> RGH!
>>
>> All solutions provided sofar are both tons more complicated, then the
>> simple solution of simply having the simplefb dt node declare which
>> clocks it needs. And to make things worse all of them sofar have
>> unresolved issues (due to their complexity mostly).
>>
>> With the clocks in the simplefb node, then all a real driver has to 
>> do,
>> is claim those same clocks before unregistering the simplefb driver,
>> and everything will just work.
>>
>> Yet we've been discussing this for months, all because of some
>> vague worries from Thierry, and *only* from Thierry that this will
>> make simplefb less generic / not abstract enough, while a simple
>> generic clocks property is about as generic as things come.

 Note: I haven't been following this thread, and really don't have the 
 time to get involved, but I did want to point out one thing:

 As I think I mentioned very early on in this thread, one of the big 
 concerns when simplefb was merged was that it would slowly grow and 
 become a monster. As such, a condition of merging it was that it would 
 not grow features like resource management at all. That means no 
 clock/regulator/... support. It's intended as a simple stop-gap 
 between early platform bringup and whenever a real driver exists for 
 the HW. If you need resource management, write a HW-specific driver. 
 The list archives presumably have a record of the discussion, but I 
 don't know the links off the top of my head. If nobody
 other than Thierry is objecting, presumably the people who originally 
 objected simply haven't noticed this patch/thread. I suppose it's 
 possible they changed their mind.

 BTW, there's no reason that the simplefb code couldn't be refactored 
 out into a support library that's used by both the simplefb we 
 currently have and any new HW-specific driver. It's just that the 
 simplefb binding and driver shouldn't grow.
>>>
>>> The whole reason why we want to use simplefb is not just to get things
>>> running until HW specific driver is in place, but also to have early 
>>> console
>>> output (to help debugging boot problems on devices without a serial 
>>> console),
>>> in a world where most video drivers are build as loadable modules, so we
>>> won't have video output until quite late into the boot process.
>>
>> You need both.
>>
>> 1) temporary early boot console -- this is nothing but an address in
>> RAM and the x/y layout. The character set from framebuffer is built
>> into the kernel.  The parallel to this is early-printk and how it uses
>> the UARTs without interrupts. This console vaporizes late in the boot
>> process -- the same thing happens with the early printk UART driver.
>> EARLYPRINTK on the command line enables this.
>>
>> 2) a device specific driver -- this sits on initrd and it loaded as
>> soon as possible. The same thing happens with the real UART driver for
>> the console. CONSOLE= on the command line causes the transition. There
>> is an API in the kernel to do this transition, I believe it is called
>> set_console() but it's been a while.
>
> Eventually we need both, yes. But 1) should stay working until 2) loads,
> not until some phase of the bootup is completed, but simply until 2) 
> loads.

 No, that is where you get into trouble. The device specific driver has
 to go onto initrd where it can be loaded as early in the boot process
 as possible.
>>>
>>> This is an argument in the "you cannot do that" / "your use case is not 
>>> valid"
>>> category, IOW this is not a technical argument. You say I cannot do that I
>>> say I can, deadlock.
>>
>> It is certainly possible to extend an earlyframebuffer to be able to
>> run as a user space console. It is just going to turn into a
>> Frankenmonster driver with piles of device specific, sp

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

[Hans de Goede]

Hi,

On 10/02/2014 03:34 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek  wrote:
>> On 2 October 2014 14:56, jonsm...@gmail.com  wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
 Hi,

 On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
 On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
 wrote:
>>> ...
> We've been over all this again and again and again.
>
> RGH!
>
> All solutions provided sofar are both tons more complicated, then the
> simple solution of simply having the simplefb dt node declare which
> clocks it needs. And to make things worse all of them sofar have
> unresolved issues (due to their complexity mostly).
>
> With the clocks in the simplefb node, then all a real driver has to 
> do,
> is claim those same clocks before unregistering the simplefb driver,
> and everything will just work.
>
> Yet we've been discussing this for months, all because of some
> vague worries from Thierry, and *only* from Thierry that this will
> make simplefb less generic / not abstract enough, while a simple
> generic clocks property is about as generic as things come.
>>>
>>> Note: I haven't been following this thread, and really don't have the 
>>> time to get involved, but I did want to point out one thing:
>>>
>>> As I think I mentioned very early on in this thread, one of the big 
>>> concerns when simplefb was merged was that it would slowly grow and 
>>> become a monster. As such, a condition of merging it was that it would 
>>> not grow features like resource management at all. That means no 
>>> clock/regulator/... support. It's intended as a simple stop-gap between 
>>> early platform bringup and whenever a real driver exists for the HW. If 
>>> you need resource management, write a HW-specific driver. The list 
>>> archives presumably have a record of the discussion, but I don't know 
>>> the links off the top of my head. If nobody
>>> other than Thierry is objecting, presumably the people who originally 
>>> objected simply haven't noticed this patch/thread. I suppose it's 
>>> possible they changed their mind.
>>>
>>> BTW, there's no reason that the simplefb code couldn't be refactored 
>>> out into a support library that's used by both the simplefb we 
>>> currently have and any new HW-specific driver. It's just that the 
>>> simplefb binding and driver shouldn't grow.
>>
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early 
>> console
>> output (to help debugging boot problems on devices without a serial 
>> console),
>> in a world where most video drivers are build as loadable modules, so we
>> won't have video output until quite late into the boot process.
>
> You need both.
>
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.
>
> 2) a device specific driver -- this sits on initrd and it loaded as
> soon as possible. The same thing happens with the real UART driver for
> the console. CONSOLE= on the command line causes the transition. There
> is an API in the kernel to do this transition, I believe it is called
> set_console() but it's been a while.

 Eventually we need both, yes. But 1) should stay working until 2) loads,
 not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>>
>>> Trying to indefinitely extend the life of the earlyprintk or
>>> earlyframeuffer is what causes problems.  Doing that forces you to
>>> basically turn them into device specific drivers which do things like
>>> claiming device specific resources and gaining device specific
>>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>>
>>
>> No. When initrd is running boot has already finished as far as kernel
>> is concerned.
>>
>> And you have to extend the life of the simplefb from the time boot has
>> finished through the time ke

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 9:23 AM, Michal Suchanek  wrote:
> On 2 October 2014 14:56, jonsm...@gmail.com  wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
>>> wrote:
>> ...
 We've been over all this again and again and again.

 RGH!

 All solutions provided sofar are both tons more complicated, then the
 simple solution of simply having the simplefb dt node declare which
 clocks it needs. And to make things worse all of them sofar have
 unresolved issues (due to their complexity mostly).

 With the clocks in the simplefb node, then all a real driver has to do,
 is claim those same clocks before unregistering the simplefb driver,
 and everything will just work.

 Yet we've been discussing this for months, all because of some
 vague worries from Thierry, and *only* from Thierry that this will
 make simplefb less generic / not abstract enough, while a simple
 generic clocks property is about as generic as things come.
>>
>> Note: I haven't been following this thread, and really don't have the 
>> time to get involved, but I did want to point out one thing:
>>
>> As I think I mentioned very early on in this thread, one of the big 
>> concerns when simplefb was merged was that it would slowly grow and 
>> become a monster. As such, a condition of merging it was that it would 
>> not grow features like resource management at all. That means no 
>> clock/regulator/... support. It's intended as a simple stop-gap between 
>> early platform bringup and whenever a real driver exists for the HW. If 
>> you need resource management, write a HW-specific driver. The list 
>> archives presumably have a record of the discussion, but I don't know 
>> the links off the top of my head. If nobody
>> other than Thierry is objecting, presumably the people who originally 
>> objected simply haven't noticed this patch/thread. I suppose it's 
>> possible they changed their mind.
>>
>> BTW, there's no reason that the simplefb code couldn't be refactored out 
>> into a support library that's used by both the simplefb we currently 
>> have and any new HW-specific driver. It's just that the simplefb binding 
>> and driver shouldn't grow.
>
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early 
> console
> output (to help debugging boot problems on devices without a serial 
> console),
> in a world where most video drivers are build as loadable modules, so we
> won't have video output until quite late into the boot process.

 You need both.

 1) temporary early boot console -- this is nothing but an address in
 RAM and the x/y layout. The character set from framebuffer is built
 into the kernel.  The parallel to this is early-printk and how it uses
 the UARTs without interrupts. This console vaporizes late in the boot
 process -- the same thing happens with the early printk UART driver.
 EARLYPRINTK on the command line enables this.

 2) a device specific driver -- this sits on initrd and it loaded as
 soon as possible. The same thing happens with the real UART driver for
 the console. CONSOLE= on the command line causes the transition. There
 is an API in the kernel to do this transition, I believe it is called
 set_console() but it's been a while.
>>>
>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>
>> No, that is where you get into trouble. The device specific driver has
>> to go onto initrd where it can be loaded as early in the boot process
>> as possible.
>>
>> Trying to indefinitely extend the life of the earlyprintk or
>> earlyframeuffer is what causes problems.  Doing that forces you to
>> basically turn them into device specific drivers which do things like
>> claiming device specific resources and gaining device specific
>> dependency knowledge, things that shouldn't be in earlyframebuffer.
>>
>
> No. When initrd is running boot has already finished as far as kernel
> is concerned.
>
> And you have to extend the life of the simplefb from the time boot has
> finished through the time kernel mounts initrd (or other root) and
> hands over to userspace found on the initrd, through the time this
> userspace searches for the kms driver and until the 

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

[Hans de Goede]

Hi,

On 10/02/2014 03:27 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
 Hi,

 On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
 On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
 wrote:
>>> ...
> We've been over all this again and again and again.
>
> RGH!
>
> All solutions provided sofar are both tons more complicated, then the
> simple solution of simply having the simplefb dt node declare which
> clocks it needs. And to make things worse all of them sofar have
> unresolved issues (due to their complexity mostly).
>
> With the clocks in the simplefb node, then all a real driver has to 
> do,
> is claim those same clocks before unregistering the simplefb driver,
> and everything will just work.
>
> Yet we've been discussing this for months, all because of some
> vague worries from Thierry, and *only* from Thierry that this will
> make simplefb less generic / not abstract enough, while a simple
> generic clocks property is about as generic as things come.
>>>
>>> Note: I haven't been following this thread, and really don't have the 
>>> time to get involved, but I did want to point out one thing:
>>>
>>> As I think I mentioned very early on in this thread, one of the big 
>>> concerns when simplefb was merged was that it would slowly grow and 
>>> become a monster. As such, a condition of merging it was that it would 
>>> not grow features like resource management at all. That means no 
>>> clock/regulator/... support. It's intended as a simple stop-gap between 
>>> early platform bringup and whenever a real driver exists for the HW. If 
>>> you need resource management, write a HW-specific driver. The list 
>>> archives presumably have a record of the discussion, but I don't know 
>>> the links off the top of my head. If nobody
>>> other than Thierry is objecting, presumably the people who originally 
>>> objected simply haven't noticed this patch/thread. I suppose it's 
>>> possible they changed their mind.
>>>
>>> BTW, there's no reason that the simplefb code couldn't be refactored 
>>> out into a support library that's used by both the simplefb we 
>>> currently have and any new HW-specific driver. It's just that the 
>>> simplefb binding and driver shouldn't grow.
>>
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early 
>> console
>> output (to help debugging boot problems on devices without a serial 
>> console),
>> in a world where most video drivers are build as loadable modules, so we
>> won't have video output until quite late into the boot process.
>
> You need both.
>
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.
>
> 2) a device specific driver -- this sits on initrd and it loaded as
> soon as possible. The same thing happens with the real UART driver for
> the console. CONSOLE= on the command line causes the transition. There
> is an API in the kernel to do this transition, I believe it is called
> set_console() but it's been a while.

 Eventually we need both, yes. But 1) should stay working until 2) loads,
 not until some phase of the bootup is completed, but simply until 2) loads.
>>>
>>> No, that is where you get into trouble. The device specific driver has
>>> to go onto initrd where it can be loaded as early in the boot process
>>> as possible.
>>
>> This is an argument in the "you cannot do that" / "your use case is not 
>> valid"
>> category, IOW this is not a technical argument. You say I cannot do that I
>> say I can, deadlock.
> 
> It is certainly possible to extend an earlyframebuffer to be able to
> run as a user space console. It is just going to turn into a
> Frankenmonster driver with piles of device specific, special case code
> in it.

There is nothing hardware specific about a framebuffer needing some
clocks to not be disabled. Tons of SoC's will have this. Which clocks,
th

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 9:14 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
 On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
>>> wrote:
>> ...
 We've been over all this again and again and again.

 RGH!

 All solutions provided sofar are both tons more complicated, then the
 simple solution of simply having the simplefb dt node declare which
 clocks it needs. And to make things worse all of them sofar have
 unresolved issues (due to their complexity mostly).

 With the clocks in the simplefb node, then all a real driver has to do,
 is claim those same clocks before unregistering the simplefb driver,
 and everything will just work.

 Yet we've been discussing this for months, all because of some
 vague worries from Thierry, and *only* from Thierry that this will
 make simplefb less generic / not abstract enough, while a simple
 generic clocks property is about as generic as things come.
>>
>> Note: I haven't been following this thread, and really don't have the 
>> time to get involved, but I did want to point out one thing:
>>
>> As I think I mentioned very early on in this thread, one of the big 
>> concerns when simplefb was merged was that it would slowly grow and 
>> become a monster. As such, a condition of merging it was that it would 
>> not grow features like resource management at all. That means no 
>> clock/regulator/... support. It's intended as a simple stop-gap between 
>> early platform bringup and whenever a real driver exists for the HW. If 
>> you need resource management, write a HW-specific driver. The list 
>> archives presumably have a record of the discussion, but I don't know 
>> the links off the top of my head. If nobody
>> other than Thierry is objecting, presumably the people who originally 
>> objected simply haven't noticed this patch/thread. I suppose it's 
>> possible they changed their mind.
>>
>> BTW, there's no reason that the simplefb code couldn't be refactored out 
>> into a support library that's used by both the simplefb we currently 
>> have and any new HW-specific driver. It's just that the simplefb binding 
>> and driver shouldn't grow.
>
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early 
> console
> output (to help debugging boot problems on devices without a serial 
> console),
> in a world where most video drivers are build as loadable modules, so we
> won't have video output until quite late into the boot process.

 You need both.

 1) temporary early boot console -- this is nothing but an address in
 RAM and the x/y layout. The character set from framebuffer is built
 into the kernel.  The parallel to this is early-printk and how it uses
 the UARTs without interrupts. This console vaporizes late in the boot
 process -- the same thing happens with the early printk UART driver.
 EARLYPRINTK on the command line enables this.

 2) a device specific driver -- this sits on initrd and it loaded as
 soon as possible. The same thing happens with the real UART driver for
 the console. CONSOLE= on the command line causes the transition. There
 is an API in the kernel to do this transition, I believe it is called
 set_console() but it's been a while.
>>>
>>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>>> not until some phase of the bootup is completed, but simply until 2) loads.
>>
>> No, that is where you get into trouble. The device specific driver has
>> to go onto initrd where it can be loaded as early in the boot process
>> as possible.
>
> This is an argument in the "you cannot do that" / "your use case is not valid"
> category, IOW this is not a technical argument. You say I cannot do that I
> say I can, deadlock.

It is certainly possible to extend an earlyframebuffer to be able to
run as a user space console. It is just going to turn into a
Frankenmonster driver with piles of device specific, special case code
in it.

I think that device specific code belongs in a device specific driver
and earlyframebuffer should handoff to it as soon as possible.

>
> I've already explained that we not only can do that (we already have working
> code proving that), but also that this is something which we absolutely need:
>
>>> One examp

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

[Michal Suchanek]

On 2 October 2014 14:56, jonsm...@gmail.com  wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
 Hi,

 On 10/01/2014 08:12 PM, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
>> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> RGH!
>>>
>>> All solutions provided sofar are both tons more complicated, then the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
>
> Note: I haven't been following this thread, and really don't have the 
> time to get involved, but I did want to point out one thing:
>
> As I think I mentioned very early on in this thread, one of the big 
> concerns when simplefb was merged was that it would slowly grow and 
> become a monster. As such, a condition of merging it was that it would 
> not grow features like resource management at all. That means no 
> clock/regulator/... support. It's intended as a simple stop-gap between 
> early platform bringup and whenever a real driver exists for the HW. If 
> you need resource management, write a HW-specific driver. The list 
> archives presumably have a record of the discussion, but I don't know the 
> links off the top of my head. If nobody
> other than Thierry is objecting, presumably the people who originally 
> objected simply haven't noticed this patch/thread. I suppose it's 
> possible they changed their mind.
>
> BTW, there's no reason that the simplefb code couldn't be refactored out 
> into a support library that's used by both the simplefb we currently have 
> and any new HW-specific driver. It's just that the simplefb binding and 
> driver shouldn't grow.

 The whole reason why we want to use simplefb is not just to get things
 running until HW specific driver is in place, but also to have early 
 console
 output (to help debugging boot problems on devices without a serial 
 console),
 in a world where most video drivers are build as loadable modules, so we
 won't have video output until quite late into the boot process.
>>>
>>> You need both.
>>>
>>> 1) temporary early boot console -- this is nothing but an address in
>>> RAM and the x/y layout. The character set from framebuffer is built
>>> into the kernel.  The parallel to this is early-printk and how it uses
>>> the UARTs without interrupts. This console vaporizes late in the boot
>>> process -- the same thing happens with the early printk UART driver.
>>> EARLYPRINTK on the command line enables this.
>>>
>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>> soon as possible. The same thing happens with the real UART driver for
>>> the console. CONSOLE= on the command line causes the transition. There
>>> is an API in the kernel to do this transition, I believe it is called
>>> set_console() but it's been a while.
>>
>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>> not until some phase of the bootup is completed, but simply until 2) loads.
>
> No, that is where you get into trouble. The device specific driver has
> to go onto initrd where it can be loaded as early in the boot process
> as possible.
>
> Trying to indefinitely extend the life of the earlyprintk or
> earlyframeuffer is what causes problems.  Doing that forces you to
> basically turn them into device specific drivers which do things like
> claiming device specific resources and gaining device specific
> dependency knowledge, things that shouldn't be in earlyframebuffer.
>

No. When initrd is running boot has already finished as far as kernel
is concerned.

And you have to extend the life of the simplefb from the time boot has
finished through the time kernel mounts initrd (or other root) and
hands over to userspace found on the initrd, through the time this
userspace searches for the kms driver and until the time it has
finally loaded if that ever succeeds.

>From the point of view of kernel once it has handed over to init in
initrd the boot is finished. The init i

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

[Hans de Goede]

Hi,

On 10/02/2014 02:56 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
>>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
 Hi,

 On 10/01/2014 08:12 PM, Stephen Warren wrote:
> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  
>> wrote:
> ...
>>> We've been over all this again and again and again.
>>>
>>> RGH!
>>>
>>> All solutions provided sofar are both tons more complicated, then the
>>> simple solution of simply having the simplefb dt node declare which
>>> clocks it needs. And to make things worse all of them sofar have
>>> unresolved issues (due to their complexity mostly).
>>>
>>> With the clocks in the simplefb node, then all a real driver has to do,
>>> is claim those same clocks before unregistering the simplefb driver,
>>> and everything will just work.
>>>
>>> Yet we've been discussing this for months, all because of some
>>> vague worries from Thierry, and *only* from Thierry that this will
>>> make simplefb less generic / not abstract enough, while a simple
>>> generic clocks property is about as generic as things come.
>
> Note: I haven't been following this thread, and really don't have the 
> time to get involved, but I did want to point out one thing:
>
> As I think I mentioned very early on in this thread, one of the big 
> concerns when simplefb was merged was that it would slowly grow and 
> become a monster. As such, a condition of merging it was that it would 
> not grow features like resource management at all. That means no 
> clock/regulator/... support. It's intended as a simple stop-gap between 
> early platform bringup and whenever a real driver exists for the HW. If 
> you need resource management, write a HW-specific driver. The list 
> archives presumably have a record of the discussion, but I don't know the 
> links off the top of my head. If nobody
> other than Thierry is objecting, presumably the people who originally 
> objected simply haven't noticed this patch/thread. I suppose it's 
> possible they changed their mind.
>
> BTW, there's no reason that the simplefb code couldn't be refactored out 
> into a support library that's used by both the simplefb we currently have 
> and any new HW-specific driver. It's just that the simplefb binding and 
> driver shouldn't grow.

 The whole reason why we want to use simplefb is not just to get things
 running until HW specific driver is in place, but also to have early 
 console
 output (to help debugging boot problems on devices without a serial 
 console),
 in a world where most video drivers are build as loadable modules, so we
 won't have video output until quite late into the boot process.
>>>
>>> You need both.
>>>
>>> 1) temporary early boot console -- this is nothing but an address in
>>> RAM and the x/y layout. The character set from framebuffer is built
>>> into the kernel.  The parallel to this is early-printk and how it uses
>>> the UARTs without interrupts. This console vaporizes late in the boot
>>> process -- the same thing happens with the early printk UART driver.
>>> EARLYPRINTK on the command line enables this.
>>>
>>> 2) a device specific driver -- this sits on initrd and it loaded as
>>> soon as possible. The same thing happens with the real UART driver for
>>> the console. CONSOLE= on the command line causes the transition. There
>>> is an API in the kernel to do this transition, I believe it is called
>>> set_console() but it's been a while.
>>
>> Eventually we need both, yes. But 1) should stay working until 2) loads,
>> not until some phase of the bootup is completed, but simply until 2) loads.
> 
> No, that is where you get into trouble. The device specific driver has
> to go onto initrd where it can be loaded as early in the boot process
> as possible.

This is an argument in the "you cannot do that" / "your use case is not valid"
category, IOW this is not a technical argument. You say I cannot do that I
say I can, deadlock.

I've already explained that we not only can do that (we already have working
code proving that), but also that this is something which we absolutely need:

>> One example why this is necessary is e.g. to debug things where the problem
>> is that the right module is not included in the initrd.

If we ever want ARM support to stop being about cute embedded non-sense hacks,
we must be able to have users get some meaningful output in failure cases like
this without needing to first solder a serial console to some test pads.

Regards,

Hans

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from t

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 8:39 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
>> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
 On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  wrote:
 ...
>> We've been over all this again and again and again.
>>
>> RGH!
>>
>> All solutions provided sofar are both tons more complicated, then the
>> simple solution of simply having the simplefb dt node declare which
>> clocks it needs. And to make things worse all of them sofar have
>> unresolved issues (due to their complexity mostly).
>>
>> With the clocks in the simplefb node, then all a real driver has to do,
>> is claim those same clocks before unregistering the simplefb driver,
>> and everything will just work.
>>
>> Yet we've been discussing this for months, all because of some
>> vague worries from Thierry, and *only* from Thierry that this will
>> make simplefb less generic / not abstract enough, while a simple
>> generic clocks property is about as generic as things come.

 Note: I haven't been following this thread, and really don't have the time 
 to get involved, but I did want to point out one thing:

 As I think I mentioned very early on in this thread, one of the big 
 concerns when simplefb was merged was that it would slowly grow and become 
 a monster. As such, a condition of merging it was that it would not grow 
 features like resource management at all. That means no 
 clock/regulator/... support. It's intended as a simple stop-gap between 
 early platform bringup and whenever a real driver exists for the HW. If 
 you need resource management, write a HW-specific driver. The list 
 archives presumably have a record of the discussion, but I don't know the 
 links off the top of my head. If nobody
 other than Thierry is objecting, presumably the people who originally 
 objected simply haven't noticed this patch/thread. I suppose it's possible 
 they changed their mind.

 BTW, there's no reason that the simplefb code couldn't be refactored out 
 into a support library that's used by both the simplefb we currently have 
 and any new HW-specific driver. It's just that the simplefb binding and 
 driver shouldn't grow.
>>>
>>> The whole reason why we want to use simplefb is not just to get things
>>> running until HW specific driver is in place, but also to have early console
>>> output (to help debugging boot problems on devices without a serial 
>>> console),
>>> in a world where most video drivers are build as loadable modules, so we
>>> won't have video output until quite late into the boot process.
>>
>> You need both.
>>
>> 1) temporary early boot console -- this is nothing but an address in
>> RAM and the x/y layout. The character set from framebuffer is built
>> into the kernel.  The parallel to this is early-printk and how it uses
>> the UARTs without interrupts. This console vaporizes late in the boot
>> process -- the same thing happens with the early printk UART driver.
>> EARLYPRINTK on the command line enables this.
>>
>> 2) a device specific driver -- this sits on initrd and it loaded as
>> soon as possible. The same thing happens with the real UART driver for
>> the console. CONSOLE= on the command line causes the transition. There
>> is an API in the kernel to do this transition, I believe it is called
>> set_console() but it's been a while.
>
> Eventually we need both, yes. But 1) should stay working until 2) loads,
> not until some phase of the bootup is completed, but simply until 2) loads.

No, that is where you get into trouble. The device specific driver has
to go onto initrd where it can be loaded as early in the boot process
as possible.

Trying to indefinitely extend the life of the earlyprintk or
earlyframeuffer is what causes problems.  Doing that forces you to
basically turn them into device specific drivers which do things like
claiming device specific resources and gaining device specific
dependency knowledge, things that shouldn't be in earlyframebuffer.



>
> Which means we must reserve necessary resources so that they don't get
> disabled until 2 loads.
>
> One example why this is necessary is e.g. to debug things where the problem
> is that the right module is not included in the initrd.
>
> Regards,
>
> Hans



-- 
Jon Smirl
jonsm...@gmail.com

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

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

[Hans de Goede]

Hi,

On 10/02/2014 02:22 PM, jonsm...@gmail.com wrote:
> On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
>> Hi,
>>
>> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>>> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
 On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  wrote:
>>> ...
> We've been over all this again and again and again.
>
> RGH!
>
> All solutions provided sofar are both tons more complicated, then the
> simple solution of simply having the simplefb dt node declare which
> clocks it needs. And to make things worse all of them sofar have
> unresolved issues (due to their complexity mostly).
>
> With the clocks in the simplefb node, then all a real driver has to do,
> is claim those same clocks before unregistering the simplefb driver,
> and everything will just work.
>
> Yet we've been discussing this for months, all because of some
> vague worries from Thierry, and *only* from Thierry that this will
> make simplefb less generic / not abstract enough, while a simple
> generic clocks property is about as generic as things come.
>>>
>>> Note: I haven't been following this thread, and really don't have the time 
>>> to get involved, but I did want to point out one thing:
>>>
>>> As I think I mentioned very early on in this thread, one of the big 
>>> concerns when simplefb was merged was that it would slowly grow and become 
>>> a monster. As such, a condition of merging it was that it would not grow 
>>> features like resource management at all. That means no clock/regulator/... 
>>> support. It's intended as a simple stop-gap between early platform bringup 
>>> and whenever a real driver exists for the HW. If you need resource 
>>> management, write a HW-specific driver. The list archives presumably have a 
>>> record of the discussion, but I don't know the links off the top of my 
>>> head. If nobody
>>> other than Thierry is objecting, presumably the people who originally 
>>> objected simply haven't noticed this patch/thread. I suppose it's possible 
>>> they changed their mind.
>>>
>>> BTW, there's no reason that the simplefb code couldn't be refactored out 
>>> into a support library that's used by both the simplefb we currently have 
>>> and any new HW-specific driver. It's just that the simplefb binding and 
>>> driver shouldn't grow.
>>
>> The whole reason why we want to use simplefb is not just to get things
>> running until HW specific driver is in place, but also to have early console
>> output (to help debugging boot problems on devices without a serial console),
>> in a world where most video drivers are build as loadable modules, so we
>> won't have video output until quite late into the boot process.
> 
> You need both.
> 
> 1) temporary early boot console -- this is nothing but an address in
> RAM and the x/y layout. The character set from framebuffer is built
> into the kernel.  The parallel to this is early-printk and how it uses
> the UARTs without interrupts. This console vaporizes late in the boot
> process -- the same thing happens with the early printk UART driver.
> EARLYPRINTK on the command line enables this.
> 
> 2) a device specific driver -- this sits on initrd and it loaded as
> soon as possible. The same thing happens with the real UART driver for
> the console. CONSOLE= on the command line causes the transition. There
> is an API in the kernel to do this transition, I believe it is called
> set_console() but it's been a while.

Eventually we need both, yes. But 1) should stay working until 2) loads,
not until some phase of the bootup is completed, but simply until 2) loads.

Which means we must reserve necessary resources so that they don't get
disabled until 2 loads.

One example why this is necessary is e.g. to debug things where the problem
is that the right module is not included in the initrd.

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.

[linux-sunxi] Re: [PATCH 1/2] ARM: dts: sun7i: Add mmc2_pins_a pinctrl definition

[Maxime Ripard]

On Wed, Oct 01, 2014 at 04:25:36PM +0200, Hans de Goede wrote:
> Signed-off-by: Hans de Goede 

Queued for 3.19, thanks!

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


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH 2/2] ARM: dts: sun7i: Add Mele M3 board

[Maxime Ripard]

On Wed, Oct 01, 2014 at 04:25:37PM +0200, Hans de Goede wrote:
> The Mele M3 is yet another Allwinnner based Android top set box from Mele.
> 
> It uses a housing similar to the A2000, but without the USM sata storage slot
> at the top.
> 
> It features an A20 SoC, 1G RAM, 4G eMMC (unique for Allwinner devices),
> 100Mbit ethernet, HDMI out, 3 USB A receptacles, VGA, and A/V OUT connections.
> 
> Signed-off-by: Hans de Goede 

Queued for 3.19, thanks!

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

[jonsm...@gmail.com]

On Thu, Oct 2, 2014 at 2:42 AM, Hans de Goede  wrote:
> Hi,
>
> On 10/01/2014 08:12 PM, Stephen Warren wrote:
>> On 10/01/2014 11:54 AM, jonsm...@gmail.com wrote:
>>> On Wed, Oct 1, 2014 at 1:26 PM, Hans de Goede  wrote:
>> ...
 We've been over all this again and again and again.

 RGH!

 All solutions provided sofar are both tons more complicated, then the
 simple solution of simply having the simplefb dt node declare which
 clocks it needs. And to make things worse all of them sofar have
 unresolved issues (due to their complexity mostly).

 With the clocks in the simplefb node, then all a real driver has to do,
 is claim those same clocks before unregistering the simplefb driver,
 and everything will just work.

 Yet we've been discussing this for months, all because of some
 vague worries from Thierry, and *only* from Thierry that this will
 make simplefb less generic / not abstract enough, while a simple
 generic clocks property is about as generic as things come.
>>
>> Note: I haven't been following this thread, and really don't have the time 
>> to get involved, but I did want to point out one thing:
>>
>> As I think I mentioned very early on in this thread, one of the big concerns 
>> when simplefb was merged was that it would slowly grow and become a monster. 
>> As such, a condition of merging it was that it would not grow features like 
>> resource management at all. That means no clock/regulator/... support. It's 
>> intended as a simple stop-gap between early platform bringup and whenever a 
>> real driver exists for the HW. If you need resource management, write a 
>> HW-specific driver. The list archives presumably have a record of the 
>> discussion, but I don't know the links off the top of my head. If nobody
>> other than Thierry is objecting, presumably the people who originally 
>> objected simply haven't noticed this patch/thread. I suppose it's possible 
>> they changed their mind.
>>
>> BTW, there's no reason that the simplefb code couldn't be refactored out 
>> into a support library that's used by both the simplefb we currently have 
>> and any new HW-specific driver. It's just that the simplefb binding and 
>> driver shouldn't grow.
>
> The whole reason why we want to use simplefb is not just to get things
> running until HW specific driver is in place, but also to have early console
> output (to help debugging boot problems on devices without a serial console),
> in a world where most video drivers are build as loadable modules, so we
> won't have video output until quite late into the boot process.

You need both.

1) temporary early boot console -- this is nothing but an address in
RAM and the x/y layout. The character set from framebuffer is built
into the kernel.  The parallel to this is early-printk and how it uses
the UARTs without interrupts. This console vaporizes late in the boot
process -- the same thing happens with the early printk UART driver.
EARLYPRINTK on the command line enables this.

2) a device specific driver -- this sits on initrd and it loaded as
soon as possible. The same thing happens with the real UART driver for
the console. CONSOLE= on the command line causes the transition. There
is an API in the kernel to do this transition, I believe it is called
set_console() but it's been a while.

>
> This is also the reason why we're working on adding hdmi console support
> to u-boot in the first place, to debug boot problems.
>
> So the whole "write a HW specific driver" answer just does not cut it. Just
> like we have vgacon / efifb on x86, we need something similar on ARM, and
> since ARM does not have a generic hw interface like vga, we need a firmware
> solution like efifb.
>
> So as said the whole "write a HW specific driver" just will not work, so
> that means using something like simplefb. Now I can take simplefb, copy
> it to rename it to firmwarefb or ubootfb or something, and then add the clocks
> support, but that is just silly.
>
> You indicate that you don't have the time for this discussion, and I note that
> there is no MAINTAINERS entry for drivers/video/fbdev/simplefb.c . So how 
> about
> the following, I pick up drivers/video/fbdev/simplefb.c maintainership, adding
> MAINTAINERS entry for it with my name in it. Then as the maintainer it will be
> my responsibility (and in my own benefit) to stop this from growing into
> a monster ?
>
> To me that seems better then adding a new drivers/video/fbdev/firmwarefb.c
> which will be just a copy with the clocks added.
>
> Regards,
>
> Hans



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

[linux-sunxi] Re: [PATCH v2 0/3] ARM: dts: sun7i: Add Banana Pi board

[Maxime Ripard]

On Wed, Oct 01, 2014 at 09:26:03AM +0200, Hans de Goede wrote:
> Hi Maxime,
> 
> Here is v2 of the Bananapi board addition. Sorry for taking so long.
> 
> Changes from v2:
> -Move uart3_pins definition from a20-sun7i-bananapi.dts to a20-sun7i.dtsi,
>  the addition of the pinctrl node is done in a separate patch
> -Use the new dual license header as license header

Merged all three for 3.19. Thanks!

Maxime

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


signature.asc
Description: Digital signature

Re: [linux-sunxi] Re: gslx680 driver ported to sunxi

[Joe Burmeister]

Hi Kristijan,

OMG, there is the full source already ported to Sunxi!
To get it working for GNU/Linux I had to find and port some random SoC 
GSLx driver over!


About the only concrete thing I'd say mine has over this is that mine 
loads firmware from a separate file.


I'll have to do a more complete comparison. Maybe a rebase. Firmware 
must be a separate file to scale to a generic driver.


At some point I really should look into the mainlining effort and making 
it support Device Tree, I'm just got next to no time at all spare for 
this. :-(



Joe



On 02/10/14 09:29, Kristijan Vrban wrote:

Hi Joe,

it was not necessary to extract the firmware. I just used this fw source:
http://dl.linux-sunxi.org/SDK/A23-v1.0/unpacked/A23/lichee/linux-3.4/drivers/input/touchscreen/gslx680/gsl1680_k70.h

Which is working with the Q88 touch panel. We just had issues to 
solder the gsl1680 manually without electrical shorts :)


Kristijan


Am Mittwoch, 1. Oktober 2014 23:00:54 UTC+2 schrieb Joe Burmeister:

Hi Kristijan,

Not sure quite what your after, but here is a new, not tested yet
(would have to dig up the tablet), firmware extractor.

It uses just readelf, objcopy and dd. Quick and dirty "python for
shell" implementation.

Hopefully this should help.

Joe



On 01/10/14 10:00, Kristijan Vrban wrote:

Hello,

attached is a gslX680.ko module from a Q88 A23 based tablet (the
cheap USD 32 devices) I just started to extract the firmware to
use gsl1680 IC with the touch panels that are used in this Q88
devices.

I think "GSL1680_K70_FW" should be the one. from this module.

Attached is also a small PCB design made in eagle to make test
connection between that touch panels and I2C interface. Maybe it
is useful for someone.

Kristijan




-- 
You received this message because you are subscribed to a topic

in the Google Groups "linux-sunxi" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/unsubscribe
.
To unsubscribe from this group and all its topics, send an email
to linux-sunxi...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout
.


--
You received this message because you are subscribed to a topic in the 
Google Groups "linux-sunxi" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/unsubscribe.
To unsubscribe from this group and all its topics, 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

[Thierry Reding]

On Wed, Oct 01, 2014 at 08:43:27PM +0200, Geert Uytterhoeven wrote:
> On Wed, Oct 1, 2014 at 7:17 PM, Mark Brown  wrote:
> >> Well, I don't think it should because it describes the same resources
> >> that the device tree node for the real device already describes. But
> >> perhaps this is one of the cases where duplication isn't all that bad?
> >
> > If we were worried about this wecould also do it by referring to
> > those nodes and saying "get all the resources these things need" rather
> > than duplicating the references (this might make it easier to work out
> > when the system is ready to hand off to the real drivers).
> 
> You can have a single node for both simplefb and the later "real" driver.
> DT describes the hardware, not the software ecosystem running on the
> hardware. Clock, regulators, etc. don't change from a hardware point of
> view.
> 
> If the firmware initialized a suitable graphics mode, it just has to add
> "linux,simplefb" to the compatible property (and perhaps a few other
> simplefb-specific properties).

Unfortunately I don't think that's going to work. Especially on ARM SoCs
there is no single node for a display device. The display device is
typically composed of several subdevices.

Thierry


pgpuH2r96AUtv.pgp
Description: PGP signature

Re: [linux-sunxi] Re: gslx680 driver ported to sunxi

[Kristijan Vrban]

Hi Joe, 

it was not necessary to extract the firmware. I just used this fw source:
http://dl.linux-sunxi.org/SDK/A23-v1.0/unpacked/A23/lichee/linux-3.4/drivers/input/touchscreen/gslx680/gsl1680_k70.h

Which is working with the Q88 touch panel. We just had issues to solder the 
gsl1680 manually without electrical shorts :)

Kristijan


Am Mittwoch, 1. Oktober 2014 23:00:54 UTC+2 schrieb Joe Burmeister:
>
>  Hi Kristijan,
>
> Not sure quite what your after, but here is a new, not tested yet (would 
> have to dig up the tablet), firmware extractor.
>
> It uses just readelf, objcopy and dd. Quick and dirty "python for shell" 
> implementation.
>
> Hopefully this should help.
>
> Joe
>
>
>
> On 01/10/14 10:00, Kristijan Vrban wrote:
>  
> Hello, 
>
>  attached is a gslX680.ko module from a Q88 A23 based tablet (the cheap 
> USD 32 devices) I just started to extract the firmware to use gsl1680 IC 
> with the touch panels that are used in this Q88 devices.
>
>  I think "GSL1680_K70_FW" should be the one. from this module.
>
>  Attached is also a small PCB design made in eagle to make test 
> connection between that touch panels and I2C interface. Maybe it is useful 
> for someone.
>
>  Kristijan
>
>  
>  
>  
>  -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "linux-sunxi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> linux-sunxi...@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

[Thierry Reding]

On Wed, Oct 01, 2014 at 06:17:04PM +0100, Mark Brown wrote:
> On Wed, Oct 01, 2014 at 02:48:53PM +0200, Thierry Reding wrote:
> > On Wed, Oct 01, 2014 at 01:20:08PM +0100, Mark Brown wrote:
[...]
> > >and that the DT must not contain any hint of simplefb as
> > > shipped separately.
> 
> > Well, I don't think it should because it describes the same resources
> > that the device tree node for the real device already describes. But
> > perhaps this is one of the cases where duplication isn't all that bad?
> 
> If we were worried about this wecould also do it by referring to
> those nodes and saying "get all the resources these things need" rather
> than duplicating the references (this might make it easier to work out
> when the system is ready to hand off to the real drivers).

That's problematic to some degree because not all resource types may
have a binding that allows them to be automatically probed, so it could
be difficult to implement "get all the resources this thing needs". But
perhaps we can come up with good enough heuristics to make that work
reliably.

One downside of that is that there may be a lot of components involved
in getting display to work and not all resources may be needed to keep
the current state running, so we may be claiming too many. But given
that we'd eventually release all of them anyway this shouldn't be too
much of an issue.

> > > That's never going to work well as far as I can see
> > > but doesn't seem like an ABI stability issue, or at least not a
> > > reasonable one.
> 
> > It would work well under the assumption that the kernel wouldn't be
> > touching any of the resources that simplefb depends on. If that's not a
> > reasonable assumption then I think we can't make simplefb work the way
> > it's currently written.
> 
> I can't see how that's reasonable unless the kernel has some way of
> figuring out what it shouldn't be touching.

Agreed. It's become clear in this discussion that we can't do this in
the way x86 and other more firmware-oriented architectures do it. They
get away with it because they in fact hide all of this in the firmware
or don't provide a way to control the resources in such a fine-grained
manner to begin with.

Thierry


pgpg3RGNrnKTX.pgp
Description: PGP signature

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

[Thierry Reding]

On Wed, Oct 01, 2014 at 11:17:23AM -0700, Mike Turquette wrote:
> On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding
>  wrote:
> > On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote:
> >> Quoting Thierry Reding (2014-09-29 06:54:00)
> >> > 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.
> >>
> >> From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001
> >> From: Mike Turquette 
> >> Date: Tue, 30 Sep 2014 14:24:38 -0700
> >> Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused
> >>
> >> Refine the definition around clk_ignore_unused, which caused some
> >> confusion recently on the linux-fbdev and linux-arm-kernel mailing
> >> lists[0].
> >>
> >> [0] http://lkml.kernel.org/r/<20140929135358.GC30998@ulmo>
> >>
> >> Signed-off-by: Mike Turquette 
> >> ---
> >> Thierry,
> >>
> >> Please let me know if this wording makes the feature more clear.
> >
> > I think that's better than before, but I don't think it's accurate yet.
> > As pointed out by Maxime unused clock may still be disabled if it's part
> > of a tree and that tree is being disabled because there are no users
> > left.
> 
> It is entirely accurate. This feature does in fact "prevent the clock
> framework from *automatically* gating clock ...".

According to what Maxime said if an unused clock is a sibling (has the
same parent) of a clock that is used and then gets disabled, then if the
parent has no other clocks that are enabled, the unused clock will still
be disabled.

That's still counts as "automatically" to me. Not automatically would
mean that the clock needs to be disabled explicitly for it to become
disabled. Disabling it as a side-effect of its parent getting disabled
is still automatic.

> And it was merged by Olof so that he could use simplefb with the
> Chromebook!

And presumably it does work for that specific Chromebook. It seems,
though that for hardware with a somewhat whackier clock tree it doesn't
work so well. As far as I can tell that's the reason for this patch and
the ensuing discussion in the first place.

Although, perhaps nobody ever really tested whether or not the above
scenario was actually a problem for sunxi and maybe clk_ignore_unused
would work for them. But as I understand they don't want to use it, so
this whole debate about this kernel parameter is a bit moot.

> > What I had argued is that it's unexpected behavior, because the clock
> > is still unused (or becomes unused again), therefore shouldn't be
> > disabled at that point either.
> 
> Leaving clocks enabled because nobody claimed them is not an option.

But that's exactly what clk_ignore_unused is, isn't it? I'm now totally
confused.

> > So if you want to keep the current behaviour where an unused clock can
> > still be disabled depending on what other users do, then I think it'd be
> > good to mention that as a potential caveat.
> 
> Do you have a suggestion on the wording?

Perhaps something like this:

Note that if an unused clock shares a parent with clocks th

[linux-sunxi] Re: [PATCH] sunxi: Add support for the Mele M3 board

[Ian Campbell]

On Wed, 2014-10-01 at 16:23 +0200, Hans de Goede wrote:
> The Mele M3 is yet another Allwinnner based Android top set box from Mele.
> 
> It uses a housing similar to the A2000, but without the USM sata storage slot
> at the top.
> 
> It features an A20 SoC, 1G RAM, 4G eMMC (unique for Allwinner devices),
> 100Mbit ethernet, HDMI out, 3 USB A receptacles, VGA, and A/V OUT connections.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 


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