[linux-sunxi] Re: [PATCH v2] mmc: sunxi: Don't start commands while the card is busy
在 2015/7/29 3:22, Arend van Spriel 写道:
On 07/21/2015 02:15 PM, Ulf Hansson wrote:
On 10 July 2015 at 17:14, Hans de Goede wrote:
Some sdio wifi modules have not been working reliable with the sunxi-mmc
host code. This turns out to be caused by it starting new commands while
the card signals that it is still busy processing a previous command.
Which are those commands? Or more interesting, which response types do
these commands expect?
I don't think this is a sunxi specific issue, I have seen similar
issues for other host controllers.
Indeed. A similar fix was needed for dw_mmc host controller.
bit 10 in STATUS register of sysnopsys dw_mmc should be issued each time
you start a new cmd. It's hard to say whetehr a local hack or not,
because it's a mandatory requirement from IP databook(refer to
"Sysnopsys DesignWare cores Mobile Storage Host Databook" Chapter 7-
Programming the DWC_mobile_storage).
Bit 10: indicate state-machine is ready, controller MUST guarantee all
I/O used in "free state", actually high.
If dw_mmc's state-machine isn't ready, NO cmd can be issued, which means
even we configure cmd and cmdarg, start bit cannot be auto-clean by
controller that leads to no cmd_done interrupt generated which dw_mmc's
tasklet state-machine need.
I am thinking that perhaps this should be managed by the mmc core
instead of local hacks to sunxi. Potentially we could make the core to
invoke the already existing host_ops->card_busy() callback when
needed...
The problem here is that there are a number of host controllers out
there not implementing that callback. That may be because the hardware
is dealing properly with busy signalling, but I would not bet on that.
Regards,
Arend
Within this context, could I ask whether you controller supports IRQ
based HW-busy detection? Or you need polling of the status register?
This commit fixes this, thereby fixing the wifi reliability issues on
the Cubietruck and other sunxi boards using sdio wifi.
Reported-by: Eugene K
Suggested-by: Eugene K
Cc: Eugene K
Cc: Arend van Spriel
Signed-off-by: Hans de Goede
---
Changes in v2:
-Properly accredit Eugene K for coming up with the fix for this
---
drivers/mmc/host/sunxi-mmc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 4d3e1ff..daa90b7 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -289,6 +289,24 @@ static int sunxi_mmc_init_host(struct mmc_host
*mmc)
return 0;
}
+/* Wait for card to report ready before starting a new cmd */
+static int sunxi_mmc_wait_card_ready(struct sunxi_mmc_host *host)
+{
+ unsigned long expire = jiffies + msecs_to_jiffies(500);
+ u32 rval;
+
+ do {
+ rval = mmc_readl(host, REG_STAS);
+ } while (time_before(jiffies, expire) && (rval &
SDXC_CARD_DATA_BUSY));
+
+ if (rval & SDXC_CARD_DATA_BUSY) {
+ dev_err(mmc_dev(host->mmc), "Error R1 ready timeout\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static void sunxi_mmc_init_idma_des(struct sunxi_mmc_host *host,
struct mmc_data *data)
{
@@ -383,6 +401,8 @@ static void sunxi_mmc_send_manual_stop(struct
sunxi_mmc_host *host,
u32 arg, cmd_val, ri;
unsigned long expire = jiffies + msecs_to_jiffies(1000);
+ sunxi_mmc_wait_card_ready(host);
+
cmd_val = SDXC_START | SDXC_RESP_EXPIRE |
SDXC_STOP_ABORT_CMD | SDXC_CHECK_RESPONSE_CRC;
@@ -597,6 +617,11 @@ static int sunxi_mmc_oclk_onoff(struct
sunxi_mmc_host *host, u32 oclk_en)
{
unsigned long expire = jiffies + msecs_to_jiffies(250);
u32 rval;
+ int ret;
+
+ ret = sunxi_mmc_wait_card_ready(host);
+ if (ret)
+ return ret;
rval = mmc_readl(host, REG_CLKCR);
rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
@@ -785,6 +810,13 @@ static void sunxi_mmc_request(struct mmc_host
*mmc, struct mmc_request *mrq)
return;
}
+ ret = sunxi_mmc_wait_card_ready(host);
+ if (ret) {
+ mrq->cmd->error = ret;
+ mmc_request_done(mmc, mrq);
+ return;
+ }
+
if (data) {
ret = sunxi_mmc_map_dma(host, data);
if (ret < 0) {
--
2.4.3
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Shawn Lin
--
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: [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
> IMHO for a common maximum opp that's a good approach. But for the lowest > frequency setting, it would seem more logical to me, to raise the voltage > to a point where all boards will run fine with them, unless those boards > cannot handle the frequency regardless of the higher voltage. I generally agre, tho IIRC some measurements seem to indicate that the lowest frequency settings did not bring much (if any) reduction in power consumption, making them rather useless. Stefan -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2] mmc: sunxi: Don't start commands while the card is busy
On 07/21/2015 02:15 PM, Ulf Hansson wrote:
On 10 July 2015 at 17:14, Hans de Goede wrote:
Some sdio wifi modules have not been working reliable with the sunxi-mmc
host code. This turns out to be caused by it starting new commands while
the card signals that it is still busy processing a previous command.
Which are those commands? Or more interesting, which response types do
these commands expect?
I don't think this is a sunxi specific issue, I have seen similar
issues for other host controllers.
Indeed. A similar fix was needed for dw_mmc host controller.
I am thinking that perhaps this should be managed by the mmc core
instead of local hacks to sunxi. Potentially we could make the core to
invoke the already existing host_ops->card_busy() callback when
needed...
The problem here is that there are a number of host controllers out
there not implementing that callback. That may be because the hardware
is dealing properly with busy signalling, but I would not bet on that.
Regards,
Arend
Within this context, could I ask whether you controller supports IRQ
based HW-busy detection? Or you need polling of the status register?
This commit fixes this, thereby fixing the wifi reliability issues on
the Cubietruck and other sunxi boards using sdio wifi.
Reported-by: Eugene K
Suggested-by: Eugene K
Cc: Eugene K
Cc: Arend van Spriel
Signed-off-by: Hans de Goede
---
Changes in v2:
-Properly accredit Eugene K for coming up with the fix for this
---
drivers/mmc/host/sunxi-mmc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 4d3e1ff..daa90b7 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -289,6 +289,24 @@ static int sunxi_mmc_init_host(struct mmc_host *mmc)
return 0;
}
+/* Wait for card to report ready before starting a new cmd */
+static int sunxi_mmc_wait_card_ready(struct sunxi_mmc_host *host)
+{
+ unsigned long expire = jiffies + msecs_to_jiffies(500);
+ u32 rval;
+
+ do {
+ rval = mmc_readl(host, REG_STAS);
+ } while (time_before(jiffies, expire) && (rval & SDXC_CARD_DATA_BUSY));
+
+ if (rval & SDXC_CARD_DATA_BUSY) {
+ dev_err(mmc_dev(host->mmc), "Error R1 ready timeout\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static void sunxi_mmc_init_idma_des(struct sunxi_mmc_host *host,
struct mmc_data *data)
{
@@ -383,6 +401,8 @@ static void sunxi_mmc_send_manual_stop(struct
sunxi_mmc_host *host,
u32 arg, cmd_val, ri;
unsigned long expire = jiffies + msecs_to_jiffies(1000);
+ sunxi_mmc_wait_card_ready(host);
+
cmd_val = SDXC_START | SDXC_RESP_EXPIRE |
SDXC_STOP_ABORT_CMD | SDXC_CHECK_RESPONSE_CRC;
@@ -597,6 +617,11 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host
*host, u32 oclk_en)
{
unsigned long expire = jiffies + msecs_to_jiffies(250);
u32 rval;
+ int ret;
+
+ ret = sunxi_mmc_wait_card_ready(host);
+ if (ret)
+ return ret;
rval = mmc_readl(host, REG_CLKCR);
rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
@@ -785,6 +810,13 @@ static void sunxi_mmc_request(struct mmc_host *mmc, struct
mmc_request *mrq)
return;
}
+ ret = sunxi_mmc_wait_card_ready(host);
+ if (ret) {
+ mrq->cmd->error = ret;
+ mmc_request_done(mmc, mrq);
+ return;
+ }
+
if (data) {
ret = sunxi_mmc_map_dma(host, data);
if (ret < 0) {
--
2.4.3
Kind regards
Uffe
--
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] Using usbtv driver on A20
Hi Armando, I'm having the same issues you had trying to load the usbtv kernel module into a Sunxi Linux system (A20-based Cubieboard2). How did you manage to cross-compile and load the backport drivers to the target kernel? I'm doing precisely the same steps you mention, but my backport drivers are build for my host machine (ubuntu x86), instead of my target machine (ARM)? Here is the modinfo output from a cross-compiled driver (sunxi_cedar_mod.ko) from my kernel sources: version:0.01alpha license:GPL description:User mode CEDAR device interface author: Soft-Allwinner srcversion: DF883A231D91233BDAC03C7 depends: intree: Y vermagic: 3.4.103-g9a1cd03-dirty SMP preempt mod_unload modversions ARMv7 p2v8 parm: g_dev_major:int parm: g_dev_minor:int And here is the output from a cross-compiled backport driver (v4l2-common.ko): license:GPL description:misc helper functions for v4l2 device drivers author: Bill Dirks, Justin Schoeman, Gerd Knorr srcversion: 2E58A890BED986B84F9BF18 depends:videodev vermagic: 3.13.0-53-generic SMP mod_unload modversions If you could share some ideas on how to overcome this, I would very much appreciate. Thanks in advance. Weber Em segunda-feira, 5 de maio de 2014 04:29:39 UTC-3, hmand...@gmail.com escreveu: > > Hi Julian, > > > Firstly, you _must_ supply more information than this > sorry, i using debian wheezy in a virtual machine to build linux-sunxi > kernel and modules. I using kernel 3.4.67+ (from stable sunxi-3.4) and > backports-3.13.2-1. > > i setup build as follow: > $ set -a > $ CROSS_COMPILE=arm-linux-gnueabihf- > $ ARCH=arm > $ KLIB_BUILD=/home/debian/a20_kernel_3.4/linux-sunxi > $ KLIB=/lib/modules/3.4.67+ > $ set +a > > $ make menuconfig: >Multimedia support > Cameras/video grabbers support >Multimedia support > Media USB Adapters > USBTV007 video capture support > > $ make > > this is make result: > http://pastebin.com/raw.php?i=MsSstVCZ > > > -- 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] SPDIF and I2S on top of sunxi-wip
Hi All, I've just pushed a load of patches towards my github fork https://github.com/codekipper/linux-sunxi/commits/audio_mainlining which now gives spdif functionality to the Mele A1000 boards. There is also additional patches that bring I2S into the kernel however I've not had a chance to verify this. I must thank Andrea Venturi for helping out with this task, he debugged my driver and helped with my development setup. He has been able to get I2S singing with the uda1380 connect to a Olimex A20 EVB. I wanted to get these out ASAP as I'm off on vacation tomorrow and they've been stewing for ages. When I'm back we'll start the process of getting these into mainline. I know that things can be broken on sunxi-wip (for example I can't get the audio codec to work on it at the moment whereas it works on linux-next) but I realise that a lot of people do use it. If anybody can test thisand feed back any issues that would be great. I've played 44100Hz and 192000Hz flacs and they sound ace. On linux-sunxi 3.4 192K flacs would stutter. The correct probe order for the spdif modules are as follows: modprobe snd-soc-sunxi-dai-spdif modprobe snd-soc-sunxi-machine-spdif with my debian setup they seem to hotplug without issue. Enjoy, CK -- 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, On 07/28/2015 05:09 PM, Timo Sigurdsson wrote: Hi, Hans de Goede schrieb am 28.07.2015 16:24: I've no problem with Timo submitting a cleaned up version of his patch and you taking that instead. I just wanted to point out that I do have a similar patch pending. Ok, I will do that. It might take a couple of days, though, as I will be moving moving in the next few days as well. However, another question first then: What maximum voltage for the dcdc2 regulator should we use then? You used 1.5V, I used 1.45V so far, which is what Cubieboard 2 and Cubietruck use. But after the discussion about overvoltaged settings, I'm wondering whether we should limit the regulartor (and not only the opp) to 1.40V as well? Or is 1.45V ok for everybody here? The datasheets lists a max cpu-voltage of 1.40V, so lets stick with that. 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Hans de Goede schrieb am 28.07.2015 16:24: > I've no problem with Timo submitting a cleaned up version of his > patch and you taking that instead. I just wanted to point out that > I do have a similar patch pending. Ok, I will do that. It might take a couple of days, though, as I will be moving moving in the next few days as well. However, another question first then: What maximum voltage for the dcdc2 regulator should we use then? You used 1.5V, I used 1.45V so far, which is what Cubieboard 2 and Cubietruck use. But after the discussion about overvoltaged settings, I'm wondering whether we should limit the regulartor (and not only the opp) to 1.40V as well? Or is 1.45V ok for everybody here? Thanks and regards, Timo -- 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Maxime Ripard schrieb am 28.07.2015 14:55: >> IMHO for a common maximum opp that's a good approach. But for the lowest >> frequency setting, it would seem more logical to me, to raise the voltage >> to a point where all boards will run fine with them, unless those boards >> cannot handle the frequency regardless of the higher voltage. > > Agreed. Ok, then I will write another patch for this as well, unless Chen-Yu or someone else objects. Regards, Timo -- 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Maxime Ripard schrieb am 28.07.2015 14:55: >> > I plan to submit this for 4.3. >> >> Ok, then I guess we can drop my patch. > > Please don't. Ok. > It was used in mainline, and reverted because it was not stable > enough. Well, the explanation given was, it was not stable because of the missing regulator support. I don't know whether anyboady actually ever reported it wouldn't run fine at 1008MHz with 1.45V. So the actual point should be whether we wan't voltages that are out of the specified range in the official kernel. The consensus seems to be no, with good reasons for that. So, I won't object this. > There's a lot of things we do differently in mainline, it's one of > them. If someone can provide an OPP for 1008MHz that is stable for all > the boards and within the operating limits of the SoC, I'd be totally > fine with that, but we didn't find it so far. > >> For those who don't want to use that setting, it's easier to >> limit the maximum in userspace compared to compiling a new device >> tree blob. > > Except that the kernel should not rely on the userspace to be stable > and harmless for the hardware. It should just work reliably by itself. Same as above. Regards, Timo -- 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Maxime Ripard schrieb am 28.07.2015 14:49: > I don't feel like holding patches that were posted before you did > because you did them some time ago and never submitted them is > reasonnable and / or encouraging for new submitters of patches. > > I'd really like to get more sunxi-people contributing, and that starts > with that kind of trivial stuff. Holding them back because one of the > usual (and experienced) developpers is a bit counter-productive (and > I'm sure you still have a lot of patches to submit anyway ;)). Just for the record: I wouldn't be discouraged by that. The only thing that matters to me here is that regulator support will be added, regardless of who submitted the patch. But anyway, I will rework the patch along the statements made during this discussion. Regards, Timo -- 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, On 07/28/2015 02:49 PM, Maxime Ripard wrote: Hi, On Mon, Jul 27, 2015 at 02:43:20PM +0200, Hans de Goede wrote: Hi, On 27-07-15 14:09, public_tim...@silentcreek.de wrote: Hi, Hans de Goede schrieb am 27.07.2015 10:07: I've a simular patch here: https://github.com/jwrdegoede/linux-sunxi/commit/6a30b7d5be6012b81e5e1439a444e41c0ac1afc1 I did not submit this upstream yet as it is part of a series to enable the otg controller on the bananapi which needs axp-usb-power-supply support for which the actual powersupply driver changes are still pending. Oops, I see. Are you planning to submit this for 4.3 or later? I plan to submit this for 4.3. I don't feel like holding patches that were posted before you did because you did them some time ago and never submitted them is reasonnable and / or encouraging for new submitters of patches. I'd really like to get more sunxi-people contributing, and that starts with that kind of trivial stuff. Holding them back because one of the usual (and experienced) developpers is a bit counter-productive (and I'm sure you still have a lot of patches to submit anyway ;)). I've no problem with Timo submitting a cleaned up version of his patch and you taking that instead. I just wanted to point out that I do have a similar patch pending. 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
On Tue, Jul 28, 2015 at 11:02:16AM +0200, Timo Sigurdsson wrote: > Hi, > > Chen-Yu Tsai schrieb am 27.07.2015 15:14: > >> ChenYu (in the CC), since you did most of the original work here, do > >> you know why we have an op at 0.9 volt, but none of our boards allow the > >> voltage to go that low in the regulator settings ? > > > > I'm on vacation now, so apologies for the bad formatting. > > > > The OPPs are from a common subset > > of the settings from the fex files available > > at the time. Some fex files actually set > > min and max voltage thus eliminating > > the highest and lowest OPPs. > > > > At least that is how Maxime and I > > interpreted them. > > IMHO for a common maximum opp that's a good approach. But for the lowest > frequency setting, it would seem more logical to me, to raise the voltage > to a point where all boards will run fine with them, unless those boards > cannot handle the frequency regardless of the higher voltage. Agreed. 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: Digital signature
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
On Tue, Jul 28, 2015 at 11:02:09AM +0200, Timo Sigurdsson wrote: > Hi, > > Hans de Goede schrieb am 27.07.2015 14:43: > >>> I've a simular patch here: > >>> > >>> https://github.com/jwrdegoede/linux-sunxi/commit/6a30b7d5be6012b81e5e1439a444e41c0ac1afc1 > >>> > >>> I did not submit this upstream yet as it is part of a series to enable the > >>> otg > >>> controller on the bananapi which needs axp-usb-power-supply support for > >>> which > >>> the actual powersupply driver changes are still pending. > >> Oops, I see. Are you planning to submit this for 4.3 or later? > > > > I plan to submit this for 4.3. > > Ok, then I guess we can drop my patch. Please don't. > >>> IMHO we should just stick with the standard operating points unless we > >>> know > >>> that there are stability issues with them (such as e.g. on the A10 > >>> OlinuxIno > >>> Lime). > >> I'd be fine with that as I don't have any stability issues with the lower > >> voltages. What about the 1008MHz operating point that I "reintroduced"? It > >> was > >> dropped here [1] because there was no regulator support. > > > > That is in essence an overclocked setting, the max CPU voltage officially is > > 1.4V, I do not think that we should provide any overclocked settings in the > > official dts files. If people really want to overclock they will have to > > modify there dts themselves IMHO. > > Personally, I would be fine with that. Even though I think, it might > be good to have them in the official files just for convenience and > because people who are used to the sunxi-3.4 kernels are used to > having the 1008MHz opp (and it was in mainline for a short while, > too). It was used in mainline, and reverted because it was not stable enough. There's a lot of things we do differently in mainline, it's one of them. If someone can provide an OPP for 1008MHz that is stable for all the boards and within the operating limits of the SoC, I'd be totally fine with that, but we didn't find it so far. > For those who don't want to use that setting, it's easier to > limit the maximum in userspace compared to compiling a new device > tree blob. Except that the kernel should not rely on the userspace to be stable and harmless for the hardware. It should just work reliably by itself. > But I do understand your point, so I guess it's just something that > maintainers have to make a decision for. As I said, either way is > fine for me. > > > > Can this be reenabled > >> on board level (which means overriding the defaults inherited from > >> sun7i-a20.dtsi) or should this be done at SOC level for all boards (which > >> means we have to add regulator nodes for all boards in the first place)? > > > > Technically this is possible, but I do not think that it is a good idea. > > I guess the same applies here, too. It's something maintainers should have a > common understanding on. I don't know how much variation there is among the > A20 boards in terms of frequencies and voltages. If you look at the FEX file, a lot. But most of them are just variations of the same OPP. I value much more a set of OPPs that has been tested on a wide range of device, that we know are working reliably on all of them, over a FEX file providing a set of OPPs that for some of them have never even been tested before because the 3.4 kernel simply ignored them. 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: Digital signature
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, On Mon, Jul 27, 2015 at 02:43:20PM +0200, Hans de Goede wrote: > Hi, > > On 27-07-15 14:09, public_tim...@silentcreek.de wrote: > >Hi, > > > >Hans de Goede schrieb am 27.07.2015 10:07: > > > >>I've a simular patch here: > >> > >>https://github.com/jwrdegoede/linux-sunxi/commit/6a30b7d5be6012b81e5e1439a444e41c0ac1afc1 > >> > >>I did not submit this upstream yet as it is part of a series to enable the > >>otg > >>controller on the bananapi which needs axp-usb-power-supply support for > >>which > >>the actual powersupply driver changes are still pending. > > > >Oops, I see. Are you planning to submit this for 4.3 or later? > > I plan to submit this for 4.3. I don't feel like holding patches that were posted before you did because you did them some time ago and never submitted them is reasonnable and / or encouraging for new submitters of patches. I'd really like to get more sunxi-people contributing, and that starts with that kind of trivial stuff. Holding them back because one of the usual (and experienced) developpers is a bit counter-productive (and I'm sure you still have a lot of patches to submit anyway ;)). > >>As you can see other then you adding the cpu operating points are patches > >>are > >>identical, which is good :) > >Yep, that and you chose a slightly higher maximum voltage for the CPU. > > > >>IMHO we should just stick with the standard operating points unless we know > >>that there are stability issues with them (such as e.g. on the A10 OlinuxIno > >>Lime). > >I'd be fine with that as I don't have any stability issues with the lower > >voltages. What about the 1008MHz operating point that I "reintroduced"? It > >was > >dropped here [1] because there was no regulator support. > > That is in essence an overclocked setting, the max CPU voltage officially is > 1.4V, I do not think that we should provide any overclocked settings in the > official dts files. If people really want to overclock they will have to > modify there dts themselves IMHO. I fully agree. > > Can this be reenabled on board level (which means overriding the > >defaults inherited from sun7i-a20.dtsi) or should this be done at > >SOC level for all boards (which means we have to add regulator > >nodes for all boards in the first place)? > > Technically this is possible, but I do not think that it is a good idea. And here as well. 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: Digital signature
Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Hans de Goede schrieb am 27.07.2015 14:43: >>> I've a simular patch here: >>> >>> https://github.com/jwrdegoede/linux-sunxi/commit/6a30b7d5be6012b81e5e1439a444e41c0ac1afc1 >>> >>> I did not submit this upstream yet as it is part of a series to enable the >>> otg >>> controller on the bananapi which needs axp-usb-power-supply support for >>> which >>> the actual powersupply driver changes are still pending. >> Oops, I see. Are you planning to submit this for 4.3 or later? > > I plan to submit this for 4.3. Ok, then I guess we can drop my patch. >>> IMHO we should just stick with the standard operating points unless we know >>> that there are stability issues with them (such as e.g. on the A10 OlinuxIno >>> Lime). >> I'd be fine with that as I don't have any stability issues with the lower >> voltages. What about the 1008MHz operating point that I "reintroduced"? It >> was >> dropped here [1] because there was no regulator support. > > That is in essence an overclocked setting, the max CPU voltage officially is > 1.4V, I do not think that we should provide any overclocked settings in the > official dts files. If people really want to overclock they will have to > modify there dts themselves IMHO. Personally, I would be fine with that. Even though I think, it might be good to have them in the official files just for convenience and because people who are used to the sunxi-3.4 kernels are used to having the 1008MHz opp (and it was in mainline for a short while, too). For those who don't want to use that setting, it's easier to limit the maximum in userspace compared to compiling a new device tree blob. But I do understand your point, so I guess it's just something that maintainers have to make a decision for. As I said, either way is fine for me. > > Can this be reenabled >> on board level (which means overriding the defaults inherited from >> sun7i-a20.dtsi) or should this be done at SOC level for all boards (which >> means we have to add regulator nodes for all boards in the first place)? > > Technically this is possible, but I do not think that it is a good idea. I guess the same applies here, too. It's something maintainers should have a common understanding on. I don't know how much variation there is among the A20 boards in terms of frequencies and voltages. If there is a lot, I'd say it would be desireable to have board-specific opp. The downside I see in my approach is that it impacts readability of the dts(i) files when settings are overridden further down the tree. Thanks and regards, Timo -- 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] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Hi, Chen-Yu Tsai schrieb am 27.07.2015 15:14: >> ChenYu (in the CC), since you did most of the original work here, do >> you know why we have an op at 0.9 volt, but none of our boards allow the >> voltage to go that low in the regulator settings ? > > I'm on vacation now, so apologies for the bad formatting. > > The OPPs are from a common subset > of the settings from the fex files available > at the time. Some fex files actually set > min and max voltage thus eliminating > the highest and lowest OPPs. > > At least that is how Maxime and I > interpreted them. IMHO for a common maximum opp that's a good approach. But for the lowest frequency setting, it would seem more logical to me, to raise the voltage to a point where all boards will run fine with them, unless those boards cannot handle the frequency regardless of the higher voltage. Regards, Timo -- 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.
