[linux-sunxi] Re: [PATCH v5 resend 0/2] phy-sun4i-usb: peripheral-mode + a31 otg workaround

2016-06-29 Thread Kishon Vijay Abraham I 
Hi,

On Wednesday 29 June 2016 11:44 PM, Hans de Goede wrote:
> Hi Kishon,
> 
> The "USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block"
> patch on which this series depends is in usb-next now:
> 
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ce15ed4c5dfb3f7757e6611902aed5db253af977
> 
> Can you please merge this series?

This is not applying cleanly against linux-phy -next. Can you rebase and send?

Thanks
Kishon

-- 
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: USB OTG on Orange Pi PC

2016-06-29 Thread boobwrt 
Nice work.
Sure i will try your path, last time i tried otg i had kernel exception when 
loading musb driver.
I would like setup usb otg in device mode as g_ether or cdrom drive emulation 
to loading bootable iso with gpio sw for iso selection yes i dream :)

But for now I try to translate audio codec driver from kernel 3.4,,,removing 
lot of config from fex file, remove undocumented R-PRCM (0x01f01400) read/Write 
(seem to be configuration area for current setting to restore after a reboot, 
not vital..), setup PLL2 (audio_pll) directly in driver since there isn't no 
clk driver PLL2 for now (I think it's related to I2S driver, and it's a complex 
clock with multi factor to adjust PLL frequency). For now i just configure it 
at 24.57Mhz/22.57Mhz and i have succes to have something in 
/sys/class/device/sunxi_codec/ and /sunxi-pcm-codec/, no kernel exception but 
no sound card available :(
When i see in sun4i audio driver, there is lot of new code to create card in 
/dev/snd/... 
It's seem I'm lost deeply in nowhere for now, but I will try your work for sure 
(just one source of kernel opps at the same time!).

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

[linux-sunxi] Re: [PATCH v5 resend 0/1] usb: musb: sunxi: Simplify dr_mode handling

2016-06-29 Thread Bin Liu 
Hi,

On Wed, Jun 29, 2016 at 08:16:39PM +0200, Hans de Goede wrote:
> Hi Bin Liu,
> 
> The "USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block"
> patch on which this patch indirectly depends is in usb-next now:
> 
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ce15ed4c5dfb3f7757e6611902aed5db253af977
> 
> Can you please merge this now?

Sure.

> 
> Regards,
> 
> Hans

Regards,
-Bin.

-- 
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 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

2016-06-29 Thread Ondřej Jirman 
On 29.6.2016 22:45, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote:
>> On 25.6.2016 09:02, Maxime Ripard wrote:
>>> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
 On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
> Hello,
>
> comments below.
>
> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Add label to the first cpu so that it can be referenced
>>> from derived dts files.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 9938972..82faefc 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -52,7 +52,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> -   cpu@0 {
>>> +   cpu0: cpu@0 {
>>> compatible = "arm,cortex-a7";
>>> device_type = "cpu";
>>> reg = <0>;
>>
>> Can you also set the cpu clock here? It is part of the SoC
>> and does not belong in the board DTS files.
>
> Do you mean operating-points, or something else? Different SBCs will
> probably require different combinations of operating points just for
> safety's sake, because they have different regulators and [some have
> botched] thermal designs, so it might make sense to customize it for
> differnt boards, and I don't feel adventurous enough setting it for all
> H3 boards out there.

 I meant clocks = <...> and clock-latency = <...>.

 These 2 are part of the SoC.

 The OPP can stay in the board files. It's a pity there's no standard
 OPP table for H3 though. :(
>>>
>>> This has never been the case, and we always had some deviation in the
>>> FEX files for all the SoCs.
>>>
>>> If we could come up with standard OPPs that work for every one,
>>> there's no reason it can't happen here.
>>>
>>> I don't really see why the thermal design should change anything. If a
>>> boards heats faster, it will throttle down to a lower OPP faster, but
>>> those OPPs are not going to change.
>>
>> I've no way to test, but I've been told some Sinovoip boards are really
>> bad in this regard (SoC is not even well thermally connected to the
>> PCB/PCB not having copper layer to spread the heat). Thermal sensor
>> readings happen at fixed intervals, so the question is if you can heat
>> up the soc from say 80°C (first trip point) to over 110°C in less than
>> that period (330ms currently).
>>
>> I say it shouldn't be a problem, if that small thing is drawing say 2W
>> at max load. It will burn or trigger a second trip point before the
>> first one has a chance to trigger and the kernel will shut down. I
>> remember tkaiser saying that he has to run that board at 240MHz max. But
>> perhaps I'm misremembering.
>>
>> I'm just speculating.
> 
> Yes, but that's just poor thermal design. What I was saying is that
> even if we really need to throttle the SoC to 240 MHz on that board
> because it heats too much, the couple of the frequency and the voltage
> will likely be the same across all boards. It's just the amount of
> time we'll spend using it that will differ.
> 
> But that's just my understanding, I might be speaking non-sense :)
> 
> Maxime
> 

You're probably right. Operating points should be part of h3.dtsi, and
if some board is particularly bad, and can't handle being above certain
frequency safely, due to thermal design issues, we can override
operating points in its dts file.

regards,
  Ondrej

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


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

2016-06-29 Thread Maxime Ripard 
Hi,

On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote:
> On 25.6.2016 09:02, Maxime Ripard wrote:
> > On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
> >> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
> >>> Hello,
> >>>
> >>> comments below.
> >>>
> >>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>  On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> > From: Ondrej Jirman 
> >
> > Add label to the first cpu so that it can be referenced
> > from derived dts files.
> >
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 9938972..82faefc 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -52,7 +52,7 @@
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > -   cpu@0 {
> > +   cpu0: cpu@0 {
> > compatible = "arm,cortex-a7";
> > device_type = "cpu";
> > reg = <0>;
> 
>  Can you also set the cpu clock here? It is part of the SoC
>  and does not belong in the board DTS files.
> >>>
> >>> Do you mean operating-points, or something else? Different SBCs will
> >>> probably require different combinations of operating points just for
> >>> safety's sake, because they have different regulators and [some have
> >>> botched] thermal designs, so it might make sense to customize it for
> >>> differnt boards, and I don't feel adventurous enough setting it for all
> >>> H3 boards out there.
> >>
> >> I meant clocks = <...> and clock-latency = <...>.
> >>
> >> These 2 are part of the SoC.
> >>
> >> The OPP can stay in the board files. It's a pity there's no standard
> >> OPP table for H3 though. :(
> > 
> > This has never been the case, and we always had some deviation in the
> > FEX files for all the SoCs.
> > 
> > If we could come up with standard OPPs that work for every one,
> > there's no reason it can't happen here.
> > 
> > I don't really see why the thermal design should change anything. If a
> > boards heats faster, it will throttle down to a lower OPP faster, but
> > those OPPs are not going to change.
> 
> I've no way to test, but I've been told some Sinovoip boards are really
> bad in this regard (SoC is not even well thermally connected to the
> PCB/PCB not having copper layer to spread the heat). Thermal sensor
> readings happen at fixed intervals, so the question is if you can heat
> up the soc from say 80°C (first trip point) to over 110°C in less than
> that period (330ms currently).
> 
> I say it shouldn't be a problem, if that small thing is drawing say 2W
> at max load. It will burn or trigger a second trip point before the
> first one has a chance to trigger and the kernel will shut down. I
> remember tkaiser saying that he has to run that board at 240MHz max. But
> perhaps I'm misremembering.
> 
> I'm just speculating.

Yes, but that's just poor thermal design. What I was saying is that
even if we really need to throttle the SoC to 240 MHz on that board
because it heats too much, the couple of the frequency and the voltage
will likely be the same across all boards. It's just the amount of
time we'll spend using it that will differ.

But that's just my understanding, I might be speaking non-sense :)

Maxime

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

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


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 1/4] ARM: dts: sun5i: Enable otg on the auxtex t004

2016-06-29 Thread Maxime Ripard 
Hi,

On Wed, Jun 29, 2016 at 08:46:59PM +0200, Hans de Goede wrote:
> The auxtek t004 has its otg usb vbus hardwired to 5v (likely in case
> people use it to power the board instead of the dedicated power micro
> usb connector), it does have an id pin, so it allows full otg
> functionality.

I don't really get what you're saying here. Is the VBUS hardcoded to
5V, without any way to switch it, or it is not wired at all?

In the former case, how can one of the PMIC output be related to the
board power input?

Thanks,
Maxime

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

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


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 4/4] ARM: dts: sun5i: Add mmc1 / sdio-wifi node to mk802

2016-06-29 Thread Maxime Ripard 
On Wed, Jun 29, 2016 at 08:47:02PM +0200, Hans de Goede wrote:
> The a10s mk802 uses a rtl8189es sdio wifi chip, add a node enabling
> the mmc1 controller, this enables using the wifi chip (together with
> an out of tree sdio driver for it).
> 
> Signed-off-by: Hans de Goede 

Applied, thanks!

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

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


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 3/4] ARM: dts: sun5i: Add axp152 pmic node to mk802

2016-06-29 Thread Maxime Ripard 
On Wed, Jun 29, 2016 at 08:47:01PM +0200, Hans de Goede wrote:
> Add a node describing the axp152 pmic to the mk802 dts, note there are
> no regulator nodes as we do not yet support the regulators on the
> axp152.
> 
> Signed-off-by: Hans de Goede 

Applied, thanks!
Maxime

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

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


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 2/4] ARM: dts: sun5i: Enable otg on the mk802

2016-06-29 Thread Maxime Ripard 
On Wed, Jun 29, 2016 at 08:47:00PM +0200, Hans de Goede wrote:
> Enable the otg controller, the id pin is not connected so enable
> it in peripheral only mode.
> 
> Signed-off-by: Hans de Goede 

Applied, thanks!
Maxime

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

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


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread Arnd Bergmann 
On Wednesday, June 29, 2016 10:54:38 PM CEST Priit Laes wrote:
> On Wed, 2016-06-29 at 21:33 +0200, Arnd Bergmann wrote:

> > What is the size of this nvram file? As it's board specific, I wonder
> > if we can simply include it inside of the DT verbatim. I remember
> > doing that (in the pre-dtb days, on real open firmware) for the
> > "spidernet"
> > ethernet driver.
> 
> It contains a bit too much info:
> 
> This is what CubieTruck requires:
> 
> http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_a
> p6210.txt

Ah, I had not realized that this is a text based interface rather than
a small binary blob with fixed offsets.

On the other hand, each line in there could be translated easily into
a separate DT property, and some of them (manfid/prodid, macaddr, ...)
look like they directly correspond to properties we already have.

As Arend said there is also the option of having a chip specific
nvram file (brcmfmac43362-sdio.txt) as a fallback when there is no
more specific module. How many of the lines in your example would
actually differ between the two? Does this affect all of them, or
just a subset that could be turned into a smaller set of DT
properties?

Arnd

-- 
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 1/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread Priit Laes 
On Wed, 2016-06-29 at 21:33 +0200, Arnd Bergmann wrote:
> On Wednesday, June 29, 2016 8:51:44 PM CEST Arend Van Spriel wrote:
> > > Typical wifi devices will have some sort of non volatile storage
> > > on board to not only store the ethernet(mac) address, but also
> > > to contain e.g. info about the antenna gain so that the firmware
> > > and/or the driver can take the antenna gain into account and
> > > ensure
> > > that they never exceed the maximum allowed broadcast strength.
> > > 
> > > However on some embedded devices there is no non-volatile storage
> > > for the wifi (for cost reasons) and instead this configuration
> > > info
> > > (which is board / pcb specific) is loaded in the form of a
> > > file which contains the contents which would normally be in the
> > > non-volatile storage.
> > > 
> > > Since we are dealing with a per-board config-file here, which is
> > > loaded from the os filesystem we really need to specify a
> > > basename
> > > here as the list of possible boards is endless, so we cannot
> > > have a lookup table in the driver.
> > 
> > As Jonas mentioned the general principle of device tree is to be
> > agnostic with regards to OS and/or driver as you undoubtedly know.
> > His
> > proposal seems like a usable solution for your problem while
> > complying
> > to the device tree principle. So instead of overriding the default
> > brcmfmac should modify it when dt specifies the "module" property,
> > ie:
> > 
> > no "module" in DT:  nvram filename = brcm/brcmfmac43362-
> > sdio.txt
> > "module=ap6210" in DT:  nvram filename = brcm/brcmfmac43362-
> > ap6210.txt
> > 
> > By the way, the example in the bindings file does not seem to
> > specify a
> > basename, but path+basename+fileext.
> 
> What is the size of this nvram file? As it's board specific, I wonder
> if we can simply include it inside of the DT verbatim. I remember
> doing that (in the pre-dtb days, on real open firmware) for the
> "spidernet"
> ethernet driver.

It contains a bit too much info:

This is what CubieTruck requires:

http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_a
p6210.txt

-- 
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] Broadcom 5Ghz and new FCC rules

2016-06-29 Thread jonsm...@gmail.com 
Does anyone have any info on how Broadcom 5Ghz chipsets work with the
new FCC rules about locked down firmware? Is it possible to get FCC
certification at 5Ghz without being forced to lock down the whole
kernel?

http://arstechnica.com/information-technology/2015/09/fcc-open-source-router-software-is-still-legal-under-certain-conditions/

Or do these new rules only apply to routers and not end devices?

-- 
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 1/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread Arnd Bergmann 
On Wednesday, June 29, 2016 8:51:44 PM CEST Arend Van Spriel wrote:
> > Typical wifi devices will have some sort of non volatile storage
> > on board to not only store the ethernet(mac) address, but also
> > to contain e.g. info about the antenna gain so that the firmware
> > and/or the driver can take the antenna gain into account and ensure
> > that they never exceed the maximum allowed broadcast strength.
> > 
> > However on some embedded devices there is no non-volatile storage
> > for the wifi (for cost reasons) and instead this configuration info
> > (which is board / pcb specific) is loaded in the form of a
> > file which contains the contents which would normally be in the
> > non-volatile storage.
> > 
> > Since we are dealing with a per-board config-file here, which is
> > loaded from the os filesystem we really need to specify a basename
> > here as the list of possible boards is endless, so we cannot
> > have a lookup table in the driver.
> 
> As Jonas mentioned the general principle of device tree is to be
> agnostic with regards to OS and/or driver as you undoubtedly know. His
> proposal seems like a usable solution for your problem while complying
> to the device tree principle. So instead of overriding the default
> brcmfmac should modify it when dt specifies the "module" property, ie:
> 
> no "module" in DT:  nvram filename = brcm/brcmfmac43362-sdio.txt
> "module=ap6210" in DT:  nvram filename = brcm/brcmfmac43362-ap6210.txt
> 
> By the way, the example in the bindings file does not seem to specify a
> basename, but path+basename+fileext.

What is the size of this nvram file? As it's board specific, I wonder
if we can simply include it inside of the DT verbatim. I remember
doing that (in the pre-dtb days, on real open firmware) for the "spidernet"
ethernet driver.

Arnd

-- 
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 1/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread 'Arend Van Spriel' via linux-sunxi 
On 29-6-2016 20:51, Arend Van Spriel wrote:
> On 29-6-2016 20:01, Hans de Goede wrote:
>> Hi,
>>
>> On 29-06-16 19:00, Kalle Valo wrote:
>>> Hans de Goede  writes:
>>>
 Hi,

 On 29-06-16 16:42, Jonas Gorski wrote:
> Hi,
>
> On 29 June 2016 at 16:04, Hans de Goede  wrote:
>> Add a brcm,nvram_file_name dt property to allow overruling the default
>> nvram filename for sdio devices. The idea is that we can specify a
>> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
>> with an ap6210 wifi sdio module and ship this in linux-firmware, so
>> that wifi will work out of the box, without requiring users to find
>> and then manually install the right nvram file for their board.
>
> Directly defining a filename doesn't seem like a good OS-agnostic
> approach. Maybe an alternative would be to add a model-property to the
> nodes (this is allowed) and make brcmfmac to request
> "FWFILENAME-" as firmware if set? That would leave it to the OS
> on how the filename is set.

 It only defines the base-filename, not the entire path, how / where
 this file is searched for / loaded-from is then left up to the os
>>>
>>> It's still a bad idea. The filename, including the path, should be
>>> created in the driver. Can't you provide chipname (or similar) via
>>> device tree and then the driver can choose what image to use?
>>
>> No, the driver already does that, but this is not ...
>>
>>> Can you tell more about the naming the firmware image, how does it work
>>> exactly?
>>
>> About firmware, this is about the nvram file which is board specific,
>> rather then chip specific.
> 
> The nvram filename is determined pretty much the same as the firmware
> filename, but indeed the nvram data is board specific. This is main
> reason why we do not submit nvram files to linux-firmware, because we
> simply do not have those files.
> 
>> Typical wifi devices will have some sort of non volatile storage
>> on board to not only store the ethernet(mac) address, but also
>> to contain e.g. info about the antenna gain so that the firmware
>> and/or the driver can take the antenna gain into account and ensure
>> that they never exceed the maximum allowed broadcast strength.
>>
>> However on some embedded devices there is no non-volatile storage
>> for the wifi (for cost reasons) and instead this configuration info
>> (which is board / pcb specific) is loaded in the form of a
>> file which contains the contents which would normally be in the
>> non-volatile storage.
>>
>> Since we are dealing with a per-board config-file here, which is
>> loaded from the os filesystem we really need to specify a basename
>> here as the list of possible boards is endless, so we cannot
>> have a lookup table in the driver.

As a note: For BT Marcel was playing with the idea of having a lookup
table on the file system which would be loaded by the driver.

> As Jonas mentioned the general principle of device tree is to be
> agnostic with regards to OS and/or driver as you undoubtedly know. His
> proposal seems like a usable solution for your problem while complying
> to the device tree principle. So instead of overriding the default
> brcmfmac should modify it when dt specifies the "module" property, ie:
> 
> no "module" in DT:nvram filename = brcm/brcmfmac43362-sdio.txt
> "module=ap6210" in DT:nvram filename = brcm/brcmfmac43362-ap6210.txt
> 
> By the way, the example in the bindings file does not seem to specify a
> basename, but path+basename+fileext.

Hans,

Another btw: Kalle has taken over maintainer job from John.

Regards,
Arend

-- 
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 1/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread 'Arend Van Spriel' via linux-sunxi 
On 29-6-2016 20:01, Hans de Goede wrote:
> Hi,
> 
> On 29-06-16 19:00, Kalle Valo wrote:
>> Hans de Goede  writes:
>>
>>> Hi,
>>>
>>> On 29-06-16 16:42, Jonas Gorski wrote:
 Hi,

 On 29 June 2016 at 16:04, Hans de Goede  wrote:
> Add a brcm,nvram_file_name dt property to allow overruling the default
> nvram filename for sdio devices. The idea is that we can specify a
> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
> with an ap6210 wifi sdio module and ship this in linux-firmware, so
> that wifi will work out of the box, without requiring users to find
> and then manually install the right nvram file for their board.

 Directly defining a filename doesn't seem like a good OS-agnostic
 approach. Maybe an alternative would be to add a model-property to the
 nodes (this is allowed) and make brcmfmac to request
 "FWFILENAME-" as firmware if set? That would leave it to the OS
 on how the filename is set.
>>>
>>> It only defines the base-filename, not the entire path, how / where
>>> this file is searched for / loaded-from is then left up to the os
>>
>> It's still a bad idea. The filename, including the path, should be
>> created in the driver. Can't you provide chipname (or similar) via
>> device tree and then the driver can choose what image to use?
> 
> No, the driver already does that, but this is not ...
> 
>> Can you tell more about the naming the firmware image, how does it work
>> exactly?
> 
> About firmware, this is about the nvram file which is board specific,
> rather then chip specific.

The nvram filename is determined pretty much the same as the firmware
filename, but indeed the nvram data is board specific. This is main
reason why we do not submit nvram files to linux-firmware, because we
simply do not have those files.

> Typical wifi devices will have some sort of non volatile storage
> on board to not only store the ethernet(mac) address, but also
> to contain e.g. info about the antenna gain so that the firmware
> and/or the driver can take the antenna gain into account and ensure
> that they never exceed the maximum allowed broadcast strength.
> 
> However on some embedded devices there is no non-volatile storage
> for the wifi (for cost reasons) and instead this configuration info
> (which is board / pcb specific) is loaded in the form of a
> file which contains the contents which would normally be in the
> non-volatile storage.
> 
> Since we are dealing with a per-board config-file here, which is
> loaded from the os filesystem we really need to specify a basename
> here as the list of possible boards is endless, so we cannot
> have a lookup table in the driver.

As Jonas mentioned the general principle of device tree is to be
agnostic with regards to OS and/or driver as you undoubtedly know. His
proposal seems like a usable solution for your problem while complying
to the device tree principle. So instead of overriding the default
brcmfmac should modify it when dt specifies the "module" property, ie:

no "module" in DT:  nvram filename = brcm/brcmfmac43362-sdio.txt
"module=ap6210" in DT:  nvram filename = brcm/brcmfmac43362-ap6210.txt

By the way, the example in the bindings file does not seem to specify a
basename, but path+basename+fileext.

Regards,
Arend

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

[linux-sunxi] [PATCH 4/4] ARM: dts: sun5i: Add mmc1 / sdio-wifi node to mk802

2016-06-29 Thread Hans de Goede 
The a10s mk802 uses a rtl8189es sdio wifi chip, add a node enabling
the mmc1 controller, this enables using the wifi chip (together with
an out of tree sdio driver for it).

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a10s-mk802.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-mk802.dts 
b/arch/arm/boot/dts/sun5i-a10s-mk802.dts
index 04120e1..c84ac00 100644
--- a/arch/arm/boot/dts/sun5i-a10s-mk802.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-mk802.dts
@@ -97,6 +97,15 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   non-removable;
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.7.4

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

[linux-sunxi] [PATCH 1/4] ARM: dts: sun5i: Enable otg on the auxtex t004

2016-06-29 Thread Hans de Goede 
The auxtek t004 has its otg usb vbus hardwired to 5v (likely in case
people use it to power the board instead of the dedicated power micro
usb connector), it does have an id pin, so it allows full otg
functionality.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts 
b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
index e15d1ef..7ddebce 100644
--- a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
@@ -130,7 +130,18 @@
status = "okay";
 };
 
+_sram {
+   status = "okay";
+};
+
  {
+   usb0_id_detect_pin: usb0_id_detect_pin@0 {
+   allwinner,pins = "PG12";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
mmc0_cd_pin_t004: mmc0_cd_pin@0 {
allwinner,pins = "PG1";
allwinner,function = "gpio_in";
@@ -164,11 +175,19 @@
status = "okay";
 };
 
+_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
 _vbus_pin_a {
allwinner,pins = "PG13";
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_id_detect_pin>;
+   usb0_id_det-gpio = < 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
 };
-- 
2.7.4

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

[linux-sunxi] [PATCH 2/4] ARM: dts: sun5i: Enable otg on the mk802

2016-06-29 Thread Hans de Goede 
Enable the otg controller, the id pin is not connected so enable
it in peripheral only mode.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a10s-mk802.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-mk802.dts 
b/arch/arm/boot/dts/sun5i-a10s-mk802.dts
index 46ff940..0bb5755 100644
--- a/arch/arm/boot/dts/sun5i-a10s-mk802.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-mk802.dts
@@ -87,6 +87,10 @@
status = "okay";
 };
 
+_sram {
+   status = "okay";
+};
+
  {
led_pins_mk802: led_pins@0 {
allwinner,pins = "PB2";
@@ -122,6 +126,11 @@
status = "okay";
 };
 
+_otg {
+   dr_mode = "peripheral";
+   status = "okay";
+};
+
  {
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
-- 
2.7.4

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

[linux-sunxi] [PATCH 3/4] ARM: dts: sun5i: Add axp152 pmic node to mk802

2016-06-29 Thread Hans de Goede 
Add a node describing the axp152 pmic to the mk802 dts, note there are
no regulator nodes as we do not yet support the regulators on the
axp152.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a10s-mk802.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-mk802.dts 
b/arch/arm/boot/dts/sun5i-a10s-mk802.dts
index 0bb5755..04120e1 100644
--- a/arch/arm/boot/dts/sun5i-a10s-mk802.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-mk802.dts
@@ -73,6 +73,20 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   axp152: pmic@30 {
+   compatible = "x-powers,axp152";
+   reg = <0x30>;
+   interrupts = <0>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_mk802>;
-- 
2.7.4

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

[linux-sunxi] [PATCH v5 resend 0/1] usb: musb: sunxi: Simplify dr_mode handling

2016-06-29 Thread Hans de Goede 
Hi Bin Liu,

The "USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block"
patch on which this patch indirectly depends is in usb-next now:

https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ce15ed4c5dfb3f7757e6611902aed5db253af977

Can you please merge this now?

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] [PATCH v5 resend 0/2] phy-sun4i-usb: peripheral-mode + a31 otg workaround

2016-06-29 Thread Hans de Goede 
Hi Kishon,

The "USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block"
patch on which this series depends is in usb-next now:

https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ce15ed4c5dfb3f7757e6611902aed5db253af977

Can you please merge this series?

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] [PATCH v5 resend 2/2] phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

2016-06-29 Thread Hans de Goede 
The A31 companion pmic (axp221) does not generate vbus change interrupts
when the board is driving vbus, so we must poll when using the pmic for
vbus-det _and_ we're driving vbus.

Signed-off-by: Hans de Goede 
Acked-by: Kishon Vijay Abraham I 
---
Changes in v2:
-No changes
Changes in v3:
-No changes
Changes in v4:
-No changes
Changes in v5:
-Rebase on top of latest linux-phy/fixes
-Added Kishon's Acked-by
---
 drivers/phy/phy-sun4i-usb.c | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index f4d1178..8c7eb33 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -95,6 +95,7 @@
 
 enum sun4i_usb_phy_type {
sun4i_a10_phy,
+   sun6i_a31_phy,
sun8i_a33_phy,
sun8i_h3_phy,
 };
@@ -125,7 +126,6 @@ struct sun4i_usb_phy_data {
/* phy0 / otg related variables */
struct extcon_dev *extcon;
bool phy0_init;
-   bool phy0_poll;
struct gpio_desc *id_det_gpio;
struct gpio_desc *vbus_det_gpio;
struct power_supply *vbus_power_supply;
@@ -353,6 +353,24 @@ static bool sun4i_usb_phy0_have_vbus_det(struct 
sun4i_usb_phy_data *data)
return data->vbus_det_gpio || data->vbus_power_supply;
 }
 
+static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data)
+{
+   if ((data->id_det_gpio && data->id_det_irq <= 0) ||
+   (data->vbus_det_gpio && data->vbus_det_irq <= 0))
+   return true;
+
+   /*
+* The A31 companion pmic (axp221) does not generate vbus change
+* interrupts when the board is driving vbus, so we must poll
+* when using the pmic for vbus-det _and_ we're driving vbus.
+*/
+   if (data->cfg->type == sun6i_a31_phy &&
+   data->vbus_power_supply && data->phys[0].regulator_on)
+   return true;
+
+   return false;
+}
+
 static int sun4i_usb_phy_power_on(struct phy *_phy)
 {
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
@@ -374,7 +392,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
phy->regulator_on = true;
 
/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
-   if (phy->index == 0 && data->vbus_det_gpio && data->phy0_poll)
+   if (phy->index == 0 && sun4i_usb_phy0_poll(data))
mod_delayed_work(system_wq, >detect, DEBOUNCE_TIME);
 
return 0;
@@ -395,7 +413,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
 * phy0 vbus typically slowly discharges, sometimes this causes the
 * Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
 */
-   if (phy->index == 0 && data->vbus_det_gpio && !data->phy0_poll)
+   if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
mod_delayed_work(system_wq, >detect, POLL_TIME);
 
return 0;
@@ -483,7 +501,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
if (vbus_notify)
extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
 
-   if (data->phy0_poll)
+   if (sun4i_usb_phy0_poll(data))
queue_delayed_work(system_wq, >detect, POLL_TIME);
 }
 
@@ -668,11 +686,6 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
}
 
data->id_det_irq = gpiod_to_irq(data->id_det_gpio);
-   data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
-   if ((data->id_det_gpio && data->id_det_irq <= 0) ||
-   (data->vbus_det_gpio && data->vbus_det_irq <= 0))
-   data->phy0_poll = true;
-
if (data->id_det_irq > 0) {
ret = devm_request_irq(dev, data->id_det_irq,
sun4i_usb_phy0_id_vbus_det_irq,
@@ -684,6 +697,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
}
}
 
+   data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
if (data->vbus_det_irq > 0) {
ret = devm_request_irq(dev, data->vbus_det_irq,
sun4i_usb_phy0_id_vbus_det_irq,
@@ -735,7 +749,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
 
 static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.num_phys = 3,
-   .type = sun4i_a10_phy,
+   .type = sun6i_a31_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-- 
2.7.4

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

[linux-sunxi] [PATCH v5 resend 1/2] phy-sun4i-usb: Add support for peripheral-only mode

2016-06-29 Thread Hans de Goede 
Use the new of_usb_get_dr_mode_by_phy() function to get the dr_mode
from the musb controller node instead of assuming that having an id_det
gpio means otg mode, and not having one means host mode.

Implement peripheral-only mode by adding a sun4i_usb_phy0_get_id_det
helper which looks at the dr_mode, always registering our extcon and
always monitoring vbus.

If dr_mode is not specified in the dts, do not register phy0 as we then
do not know how to treat it. This is actually a good thing as this means
we will not be registering phy0 on devices where the otg controller is
not enabled in the devicetree.

Signed-off-by: Hans de Goede 
Acked-by: Kishon Vijay Abraham I 
---
Changes in v2:
-Adjust for of_usb_get_dr_mode_by_phy now taking an args0 parameter
Changes in v3:
-Only toggle the phy vbus-det bit on id-change on systems without vbus-det
 when in otg mode
Changes in v4:
-No changes
Changes in v5:
-Added Kishon's Acked-by
---
 drivers/phy/phy-sun4i-usb.c | 68 ++---
 1 file changed, 46 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index de3101f..f4d1178 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define REG_ISCR   0x00
@@ -109,6 +110,7 @@ struct sun4i_usb_phy_cfg {
 struct sun4i_usb_phy_data {
void __iomem *base;
const struct sun4i_usb_phy_cfg *cfg;
+   enum usb_dr_mode dr_mode;
struct mutex mutex;
struct sun4i_usb_phy {
struct phy *phy;
@@ -119,6 +121,7 @@ struct sun4i_usb_phy_data {
bool regulator_on;
int index;
} phys[MAX_PHYS];
+   int first_phy;
/* phy0 / otg related variables */
struct extcon_dev *extcon;
bool phy0_init;
@@ -285,16 +288,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
sun4i_usb_phy0_update_iscr(_phy, 0, ISCR_DPDM_PULLUP_EN);
sun4i_usb_phy0_update_iscr(_phy, 0, ISCR_ID_PULLUP_EN);
 
-   if (data->id_det_gpio) {
-   /* OTG mode, force ISCR and cable state updates */
-   data->id_det = -1;
-   data->vbus_det = -1;
-   queue_delayed_work(system_wq, >detect, 0);
-   } else {
-   /* Host only mode */
-   sun4i_usb_phy0_set_id_detect(_phy, 0);
-   sun4i_usb_phy0_set_vbus_detect(_phy, 1);
-   }
+   /* Force ISCR and cable state updates */
+   data->id_det = -1;
+   data->vbus_det = -1;
+   queue_delayed_work(system_wq, >detect, 0);
}
 
return 0;
@@ -319,6 +316,19 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
return 0;
 }
 
+static int sun4i_usb_phy0_get_id_det(struct sun4i_usb_phy_data *data)
+{
+   switch (data->dr_mode) {
+   case USB_DR_MODE_OTG:
+   return gpiod_get_value_cansleep(data->id_det_gpio);
+   case USB_DR_MODE_HOST:
+   return 0;
+   case USB_DR_MODE_PERIPHERAL:
+   default:
+   return 1;
+   }
+}
+
 static int sun4i_usb_phy0_get_vbus_det(struct sun4i_usb_phy_data *data)
 {
if (data->vbus_det_gpio)
@@ -414,7 +424,10 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
struct phy *phy0 = data->phys[0].phy;
int id_det, vbus_det, id_notify = 0, vbus_notify = 0;
 
-   id_det = gpiod_get_value_cansleep(data->id_det_gpio);
+   if (phy0 == NULL)
+   return;
+
+   id_det = sun4i_usb_phy0_get_id_det(data);
vbus_det = sun4i_usb_phy0_get_vbus_det(data);
 
mutex_lock(>mutex);
@@ -430,7 +443,8 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
 * without vbus detection report vbus low for long enough for
 * the musb-ip to end the current device session.
 */
-   if (!sun4i_usb_phy0_have_vbus_det(data) && id_det == 0) {
+   if (data->dr_mode == USB_DR_MODE_OTG &&
+   !sun4i_usb_phy0_have_vbus_det(data) && id_det == 0) {
sun4i_usb_phy0_set_vbus_detect(phy0, 0);
msleep(200);
sun4i_usb_phy0_set_vbus_detect(phy0, 1);
@@ -456,7 +470,8 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
 * without vbus detection report vbus low for long enough to
 * the musb-ip to end the current host session.
 */
-   if (!sun4i_usb_phy0_have_vbus_det(data) && id_det == 1) {
+   if (data->dr_mode == USB_DR_MODE_OTG &&
+   !sun4i_usb_phy0_have_vbus_det(data) && id_det == 1) {
mutex_lock(>mutex);

Re: [linux-sunxi] Re: [PATCH 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name

2016-06-29 Thread Hans de Goede 

HI,

On 29-06-16 19:01, Kalle Valo wrote:

Hans de Goede  writes:


The cubietruck uses an ap6210 sdio wifi module, set brcm,nvram_file_name
to brcmfmac43362-ap6210.txt so that we can ship the ap6210 specific
nvram file in linunx-firmware to get the wifi to work out of the box
without users needing to download and install the nvram file themselves.

Note a downside of this patch is that users who have already manually
installed the nvram file will need to rename it.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 1 +
 1 file changed, 1 insertion(+)


I can't apply .dts changes so better to send them in a separate
patchset.


Maxime Ripard who is in the Cc maintains the dts files
in question, I've send these as one set because I find
that sending out actual dts usage examples helps.

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 1/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread Hans de Goede 

Hi,

On 29-06-16 19:00, Kalle Valo wrote:

Hans de Goede  writes:


Hi,

On 29-06-16 16:42, Jonas Gorski wrote:

Hi,

On 29 June 2016 at 16:04, Hans de Goede  wrote:

Add a brcm,nvram_file_name dt property to allow overruling the default
nvram filename for sdio devices. The idea is that we can specify a
board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
with an ap6210 wifi sdio module and ship this in linux-firmware, so
that wifi will work out of the box, without requiring users to find
and then manually install the right nvram file for their board.


Directly defining a filename doesn't seem like a good OS-agnostic
approach. Maybe an alternative would be to add a model-property to the
nodes (this is allowed) and make brcmfmac to request
"FWFILENAME-" as firmware if set? That would leave it to the OS
on how the filename is set.


It only defines the base-filename, not the entire path, how / where
this file is searched for / loaded-from is then left up to the os


It's still a bad idea. The filename, including the path, should be
created in the driver. Can't you provide chipname (or similar) via
device tree and then the driver can choose what image to use?


No, the driver already does that, but this is not ...


Can you tell more about the naming the firmware image, how does it work
exactly?


About firmware, this is about the nvram file which is board specific,
rather then chip specific.

Typical wifi devices will have some sort of non volatile storage
on board to not only store the ethernet(mac) address, but also
to contain e.g. info about the antenna gain so that the firmware
and/or the driver can take the antenna gain into account and ensure
that they never exceed the maximum allowed broadcast strength.

However on some embedded devices there is no non-volatile storage
for the wifi (for cost reasons) and instead this configuration info
(which is board / pcb specific) is loaded in the form of a
file which contains the contents which would normally be in the
non-volatile storage.

Since we are dealing with a per-board config-file here, which is
loaded from the os filesystem we really need to specify a basename
here as the list of possible boards is endless, so we cannot
have a lookup table in the driver.

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 2/4] ARM: dts: sun7i-a20-cubietruck: Set brcm,nvram_file_name

2016-06-29 Thread Kalle Valo 
Hans de Goede  writes:

> The cubietruck uses an ap6210 sdio wifi module, set brcm,nvram_file_name
> to brcmfmac43362-ap6210.txt so that we can ship the ap6210 specific
> nvram file in linunx-firmware to get the wifi to work out of the box
> without users needing to download and install the nvram file themselves.
>
> Note a downside of this patch is that users who have already manually
> installed the nvram file will need to rename it.
>
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 1 +
>  1 file changed, 1 insertion(+)

I can't apply .dts changes so better to send them in a separate
patchset.

-- 
Kalle Valo

-- 
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/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread Kalle Valo 
Hans de Goede  writes:

> Hi,
>
> On 29-06-16 16:42, Jonas Gorski wrote:
>> Hi,
>>
>> On 29 June 2016 at 16:04, Hans de Goede  wrote:
>>> Add a brcm,nvram_file_name dt property to allow overruling the default
>>> nvram filename for sdio devices. The idea is that we can specify a
>>> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
>>> with an ap6210 wifi sdio module and ship this in linux-firmware, so
>>> that wifi will work out of the box, without requiring users to find
>>> and then manually install the right nvram file for their board.
>>
>> Directly defining a filename doesn't seem like a good OS-agnostic
>> approach. Maybe an alternative would be to add a model-property to the
>> nodes (this is allowed) and make brcmfmac to request
>> "FWFILENAME-" as firmware if set? That would leave it to the OS
>> on how the filename is set.
>
> It only defines the base-filename, not the entire path, how / where
> this file is searched for / loaded-from is then left up to the os

It's still a bad idea. The filename, including the path, should be
created in the driver. Can't you provide chipname (or similar) via
device tree and then the driver can choose what image to use?

Can you tell more about the naming the firmware image, how does it work
exactly?

-- 
Kalle Valo

-- 
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/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread Hans de Goede 

Hi,

On 29-06-16 16:42, Jonas Gorski wrote:

Hi,

On 29 June 2016 at 16:04, Hans de Goede  wrote:

Add a brcm,nvram_file_name dt property to allow overruling the default
nvram filename for sdio devices. The idea is that we can specify a
board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
with an ap6210 wifi sdio module and ship this in linux-firmware, so
that wifi will work out of the box, without requiring users to find
and then manually install the right nvram file for their board.


Directly defining a filename doesn't seem like a good OS-agnostic
approach. Maybe an alternative would be to add a model-property to the
nodes (this is allowed) and make brcmfmac to request
"FWFILENAME-" as firmware if set? That would leave it to the OS
on how the filename is set.


It only defines the base-filename, not the entire path, how / where
this file is searched for / loaded-from is then left up to the os

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/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread Jonas Gorski 
Hi,

On 29 June 2016 at 16:04, Hans de Goede  wrote:
> Add a brcm,nvram_file_name dt property to allow overruling the default
> nvram filename for sdio devices. The idea is that we can specify a
> board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
> with an ap6210 wifi sdio module and ship this in linux-firmware, so
> that wifi will work out of the box, without requiring users to find
> and then manually install the right nvram file for their board.

Directly defining a filename doesn't seem like a good OS-agnostic
approach. Maybe an alternative would be to add a model-property to the
nodes (this is allowed) and make brcmfmac to request
"FWFILENAME-" as firmware if set? That would leave it to the OS
on how the filename is set.


Regards
Jonas

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

[linux-sunxi] [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-06-29 Thread Hans de Goede 
Add a brcm,nvram_file_name dt property to allow overruling the default
nvram filename for sdio devices. The idea is that we can specify a
board specific nvram file, e.g. brcmfmac43362-ap6210.txt for boards
with an ap6210 wifi sdio module and ship this in linux-firmware, so
that wifi will work out of the box, without requiring users to find
and then manually install the right nvram file for their board.

Signed-off-by: Hans de Goede 
---
 .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt  | 2 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c   | 2 ++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 ++
 include/linux/platform_data/brcmfmac.h  | 2 ++
 4 files changed, 12 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt 
b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
index 5dbf169..2ba13a6 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
@@ -11,6 +11,7 @@ Required properties:
 Optional properties:
  - brcm,drive-strength : drive strength used for SDIO pins on device in mA
(default = 6).
+ - brcm,nvram_file_name : name of the nvram file to load
  - interrupt-parent : the phandle for the interrupt controller to which the
device interrupts are connected.
  - interrupts : specifies attributes for the out-of-band interrupt (host-wake).
@@ -34,6 +35,7 @@ mmc3: mmc@01c12000 {
brcmf: bcrmf@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
+   brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
interrupt-parent = <>;
interrupts = <10 8>; /* PH10 / EINT10 */
interrupt-names = "host-wake";
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index 425c41d..a054122 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -36,6 +36,8 @@ void brcmf_of_probe(struct device *dev, struct 
brcmfmac_sdio_pd *sdio)
if (of_property_read_u32(np, "brcm,drive-strength", ) == 0)
sdio->drive_strength = val;
 
+   of_property_read_string(np, "brcm,nvram_file_name", >nvram_name);
+
/* make sure there are interrupts defined in the node */
if (!of_find_property(np, "interrupts", NULL))
return;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 67e69bf..2655409 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4201,6 +4201,12 @@ struct brcmf_sdio *brcmf_sdio_probe(struct 
brcmf_sdio_dev *sdiodev)
if (ret)
goto fail;
 
+   if (sdiodev->settings->bus.sdio.nvram_name) {
+   strlcpy(sdiodev->nvram_name,
+   sdiodev->settings->bus.sdio.nvram_name,
+   BRCMF_FW_NAME_LEN);
+   }
+
ret = brcmf_fw_get_firmwares(sdiodev->dev, BRCMF_FW_REQUEST_NVRAM,
 sdiodev->fw_name, sdiodev->nvram_name,
 brcmf_sdio_firmware_callback);
diff --git a/include/linux/platform_data/brcmfmac.h 
b/include/linux/platform_data/brcmfmac.h
index 1d30bf2..a5515dd 100644
--- a/include/linux/platform_data/brcmfmac.h
+++ b/include/linux/platform_data/brcmfmac.h
@@ -65,6 +65,7 @@ enum brcmf_bus_type {
  * the target drive strength, the exact drive strength
  * which will be used depends on the capabilities of the
  * device.
+ * @nvram_name:name of nvram file to load.
  * @oob_irq_supported: does the board have support for OOB interrupts. SDIO
  * in-band interrupts are relatively slow and for having
  * less overhead on interrupt processing an out of band
@@ -91,6 +92,7 @@ enum brcmf_bus_type {
 struct brcmfmac_sdio_pd {
int txglomsz;
unsigned intdrive_strength;
+   const char  *nvram_name;
booloob_irq_supported;
unsigned intoob_irq_nr;
unsigned long   oob_irq_flags;
-- 
2.7.4

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

[linux-sunxi] [PATCH 4/4] ARM: dts: sun5i-a10s-auxtek-t004: Set brcm,nvram_file_name

2016-06-29 Thread Hans de Goede 
The auxtek t004 uses a toc9002 sdio wifi module, the android nvram file
for this is for an older firmware which does not work with the mainline
kernel driver.

So we set brcm,nvram_file_name to brcmfmac43362-ap6210.txt which
works fine for this wifi module.

Setting brcm,nvram_file_name allows us to ship the ap6210 specific nvram
file in linux-firmware to get the wifi to work out of the box without
users needing to download and install the nvram file themselves.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts 
b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
index a790ec8..e15d1ef 100644
--- a/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts
@@ -118,6 +118,12 @@
non-removable;
cap-sdio-irq;
status = "okay";
+
+   brcmf: bcrmf@1 {
+   reg = <1>;
+   compatible = "brcm,bcm4329-fmac";
+   brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
+   };
 };
 
  {
-- 
2.7.4

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

[linux-sunxi] [PATCH 3/4] ARM: dts: sun7i-a20-wits-pro-a20-dkt: Set brcm,nvram_file_name

2016-06-29 Thread Hans de Goede 
The wits pro uses an ap6476 sdio wifi module, we do not have a nvram file
for this, so set brcm,nvram_file_name to brcmfmac43362-ap6210.txt which
works fine for this wifi module.

Setting brcm,nvram_file_name allows us to ship the ap6210 specific nvram
file in linux-firmware to get the wifi to work out of the box without
users needing to download and install the nvram file themselves.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts 
b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
index dc31d47..3c5455a9 100644
--- a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
+++ b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
@@ -140,6 +140,7 @@
brcmf: bcrmf@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
+   brcm,nvram_file_name = "brcm/brcmfmac43362-ap6210.txt";
interrupt-parent = <>;
interrupts = <7 10 IRQ_TYPE_LEVEL_LOW>; /* PH10 / EINT10 */
interrupt-names = "host-wake";
-- 
2.7.4

-- 
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] mmc: pwrseq-simple: Add an optional post-power-on-delay

2016-06-29 Thread Hans de Goede 

Hi,

On 23-06-16 11:33, Hans de Goede wrote:

Hi,

On 23-06-16 00:25, Rob Herring wrote:

On Wed, Jun 22, 2016 at 12:59 PM, Hans de Goede  wrote:

Some devices need a while to boot their firmware after providing clks /
de-asserting resets before they are ready to receive sdio commands.

This commits adds a post-power-on-delay-ms devicetree property to
mmc-pwrseq-simple for use with such devices.

Signed-off-by: Hans de Goede 
---
 Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++
 drivers/mmc/core/pwrseq_simple.c| 9 +
 2 files changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
index ce0e767..e254368 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
@@ -16,6 +16,8 @@ Optional properties:
   See ../clocks/clock-bindings.txt for details.
 - clock-names : Must include the following entry:
   "ext_clock" (External clock provided to the card).
+- post-power-on-delay-ms : Delay in ms after powering the card and
+   de-asserting the reset-gpios (if any)


Presumably you need this delay post any reset, not just after power on


mmc-pwrseq is only about doing power-on / off, not about providing
reset functionality.


if you are waiting for firmware to boot. So the name is not all that
clear. How about a "reset-timing-ms" property that takes 3 values for
pre-assert time (normally 0), assertion time, post assert time. Of
course, I can still think of ways that breaks like when in this
sequence do clocks need to be turned on.


If you look at bindings/mmc/mmc-pwrseq-simple.txt out side of
the diff context it contains:

- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
at initialization and prior we start the power up procedure of the card.
They will be de-asserted right after the power has been provided to the
card.
- clocks : Must contain an entry for the entry in clock-names.
  See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entry:
  "ext_clock" (External clock provided to the card).

Notice how the existing docs talk about a power-up procedure (which matches
the pwrseq name and purpose of these bindings).

I actually started with calling the property "post-reset-delay-ms", but then
I realized that what we really want is the ability to specify a time to
wait (for e.g. firmware to boot) after completing the power-up procedure
(and before starting the probe). The power-up procedure currently can
also includes enabling external clocks to the sdio device (if any) and
enabling regulators, so having a "reset-timing-ms" property does not
seem right, as that would suggest it is ok to do the wait after deasserting
reset, but before e.g. enabling external clocks. Where what we really
want is to enable all necessary resources (or iow complete the powerup
procedure) and then wait.

You're right that in some cases more complicated timings may be necessary,
but that can get really complicated like e.g.: enable regulator1, wait 10 ms,
enable regulator2, wait 15ms, enable external clock1, ...

And such complex timings fall outside of the scope of the mmc-pwrseq-simple
binding, the idea being that for complex cases we do a device specific
pwrseq binding, and then the smarts are in implementation of that specific
pwrseq driver. As you've said yourself before we do not want to turn
devicetree into a scripting language.

However having a single wait after doing a straight forward power-up cycle
seems to me like something which is appropriate for the mmc-pwrseq-simple
binding.


Rob, can you please let us know if you're happy with my explanation above
and if not explain how you would like this binding to look instead ?

Thanks & Regards,

Hans

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

[linux-sunxi] Re: [PATCH 1/3] clk: sunxi: Add a driver for the CCU

2016-06-29 Thread Jean-Francois Moine 
On Tue, 28 Jun 2016 22:45:02 +0200
Maxime Ripard  wrote:

> On Tue, Jun 28, 2016 at 05:37:35PM +0200, Jean-Francois Moine wrote:
> > +/* --- prepare / enable --- */
> > +int ccu_prepare(struct clk_hw *hw)
> > +{
> > +   struct ccu *ccu = hw2ccu(hw);
> > +
> > +   if (!ccu->reset_reg && !ccu->bus_reg)
> > +   return 0;
> > +
> > +#if CCU_DEBUG
> > +   pr_info("** ccu %s prepare\n", clk_hw_get_name(>hw));
> > +#endif
> > +   spin_lock(_lock);
> > +   if (ccu->reset_reg)
> > +   writel(readl(ccu->base + ccu->reset_reg) |
> > +   BIT(ccu->reset_bit),
> > +   ccu->base + ccu->reset_reg);
> > +   if (ccu->bus_reg)
> > +   writel(readl(ccu->base + ccu->bus_reg) | BIT(ccu->bus_bit),
> > +   ccu->base + ccu->bus_reg);
> 
> Like I already said, this is a no-go.

I don't see why: prepare/unprepare do the right job.

> > +
> > +/* --- PLL --- */
> > +static int ccu_pll_find_best(struct ccu *ccu,
> > +   unsigned long rate,
> > +   unsigned long parent_rate,
> > +   struct values *p_v)
> > +{
> > +   int max_mul, max_div, mul, div, t;
> > +   int n = 1, d1 = 1, k = 1, m = 1, p = 0;
> > +   int max_n = 1 << ccu->n_width;
> > +   int max_d1 = 1 << ccu->d1_width;
> > +   int max_k = 1 << ccu->k_width;
> > +   int max_m = 1 << ccu->m_width;
> > +   int max_p = 1 << ccu->p_width;
> > +
> > +   if (ccu->features & CCU_FEATURE_N0)
> > +   max_n--;
> > +
> > +   /* compute n */
> > +   if (max_n > 1) {
> > +   max_mul = max_n * max_k;
> > +   if (rate > parent_rate * max_mul) {
> > +   pr_err("%s: Clock rate too high %ld > %ld * %d * %d\n",
> > +   clk_hw_get_name(>hw),
> > +   rate, parent_rate, max_n, max_k);
> > +   return -EINVAL;
> > +   }
> > +   max_div = max_m * max_d1 << max_p;
> > +   if (max_div > 1) {
> > +   unsigned long lmul, ldiv;
> > +
> > +   rational_best_approximation(rate, parent_rate,
> > +   max_mul - 1,
> > +   max_div - 1,
> > +   , );
> > +   mul = lmul;
> > +   div = ldiv;
> > +   if (ccu->n_min && mul < ccu->n_min) {
> > +   t = (ccu->n_min + mul - 1) / mul;
> > +   mul *= t;
> > +   div *= t;
> > +   }
> > +   } else {
> > +   mul = (rate + parent_rate - 1) / parent_rate;
> > +   div = 1;
> > +   }
> > +
> > +   /* compute k (present only when 'n' is present) */
> > +   if (max_k > 1) {
> > +   int k_min, k_opt, delta_opt = 100, delta;
> > +
> > +   k = (mul + max_n - 1) / max_n;
> > +   k_opt = k_min = k;
> > +   for (k = max_k; k > k_min; k--) {
> > +   n = (mul + k - 1) / k;
> > +   t = n * k;
> > +   delta = t - mul;
> > +   if (delta == 0) {
> > +   k_opt = k;
> > +   break;
> > +   }
> > +   if (delta < 0)
> > +   delta = -delta;
> > +   if (delta < delta_opt) {
> > +   delta_opt = delta;
> > +   k_opt = k;
> > +   }
> > +   }
> > +   k = k_opt;
> > +   n = (mul + k - 1) / k;
> > +   } else {
> > +   n = mul;
> > +   }
> > +   } else {
> > +   div = (parent_rate + rate - 1) / rate;
> > +   }
> > +
> > +   /* compute d1 (value is only 1 or 2) */
> > +   if (max_d1 > 1) {
> > +   if (div % 2 == 0) {
> > +   d1 = 2;
> > +   div /= 2;
> > +   }
> > +   }
> > +
> > +   /* compute p */
> > +/* p = 0; */
> > +   while (div % 2 == 0 && p <= max_p) {
> > +   p++;
> > +   div /= 2;
> > +   }
> > +
> > +   /* compute m */
> > +   if (max_m > 1) {
> > +   if (div <= max_m)
> > +   m = div;
> > +   else
> > +   m = max_m;
> > +   div /= m;
> > +   }
> > +
> > +   /* adjust n */
> > +   n = DIV_ROUND_CLOSEST((rate << p) * m * d1, parent_rate);
> > +   n = DIV_ROUND_CLOSEST(n, k);
> > +
> > +   p_v->n = n;
> > +   p_v->d1 = d1;
> > +   p_v->k = k;
> > +   p_v->m = m;
> > +   p_v->p = p;
> > +
> > +   return 0;
> > +}
> 
> So. In order to move away from an unmaintainable mess, we create a new
>