Re: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
You are right. China have suffer too much from idealism. Now they come to the other way. Don't say something too beautiful to them, they don't believe that and think you are a cheater. On Mon, Oct 13, 2014 at 08:11:40AM -0700, jacky lau wrote: > I agree with you and Jhon Yi. Developing a soc is not too hard now, getting > customers is harder and more important. I hope the market will force all > China Soc company more open. But before that happen, I don't think they > will become more open. > They don't have experience in working with the open source community, if you > want > them to be more open, you need to do more communicate with them. And > remember, to them, neither the law nor the spirit of free software, but > making > money is paramount. Tell them they will get more customers, make more money > and prove it, then they will follow. > > 在 2014年10月11日星期六UTC+8下午10时53分48秒，Jon Smirl写道： > > > > On Sat, Oct 11, 2014 at 10:31 AM, jacky lau > > wrote: > > > A big client will buy thousands of chips once. Are there any relation > > > between big client and user manual publishing? No. So they don't think > > it's > > > necessary to open their private property. When you are a big client, you > > are > > > VIP, all document and source code is open to you. And if publish all > > > technical documentation, competitors will know some technical secret > > (e.g. > > > bug;) they don't want them to know. > > > Open world is beautiful, but they will not actively participate if there > > is > > > no return. Why some China soc company publish some documents and source > > code > > > now? I think this is mainly for marketing. But no matter how, VIP > > priority. > > > > Right now Allwinner is only good for tablets and STBs because > > Allwinner supplies turnkey solutions. If documentation were more open > > other applications could be developed. If customer can't get software > > working for these other applications, they won't buy thousands of > > chips. So if Allwinner wants to survive past the end of the tablet fad > > they have to start developing these other markets. Otherwise when the > > tablet fad is over it will be the end of Allwinner. > > > > You also over estimate the value of "technical secrets". What is the > > point of putting a secret h.264 encode/decode unit on the chip if half > > of your customers can't get it working? Obviously Rockchip knows how > > to make h.264 encode/decode since they have a similar unit on their > > chip. And so does Freescale, TI, ST, etc. -- there is no big secret in > > making h.264 hardware for people familiar with how to do it (hint, it > > is an ISO standard). So by keeping the documentation secret you hide > > nothing significant from your competitors and much, much worse -- you > > keep your own customers from using the hardware they bought. Think > > about it --- which is more important - hiding something form a > > competitor that they probably already know, or getting your customers > > to ship and buy more chips? > > > > Bottom line - which one brings cash in the door - secret documentation > > or getting as many customers as possible to ship? > > > > > > > > > > 在 2014年10月6日星期一UTC+8下午8时55分30秒，RFat写道： > > >> > > >> Hi Kevin, > > >> > > >> Publishing the user manuals will certainly increase Allwinner's chips > > >> popularity. > > >> > > >> I was wondering if there is a rough estimate as to when the A80's > > manual > > >> will be made available? > > >> > > >> Thanks! > > >> Raanan > > >> > > >> On Monday, September 29, 2014 12:46:53 PM UTC+3, > > ke...@allwinnertech.com > > >> wrote: > > >>> > > >>> Hi All, > > >>> > > >>> I have put the documents on github, and the url is > > >>> https://github.com/allwinner-zh/documents.git > > >>> Thanks Simos, Henrik and Luc's suggestion. And other documents will be > > >>> upated to here when released. > > >>> > > >>> > > >>> > > >>> Best Regards, > > >>> kevin.z.m > > >>> > > >>> > > >>> > > >>> From: HenrikNordström > > >>> Date: 2014-09-29 08:46 > > >>> To: linux...@googlegroups.com > > >>> CC: sh...@allwinnertech.com; Meng Zhang > > >>> Subject: Re: [linux-sunxi] Allwinner documentation (hardware > > datasheet, > > >>> user manual) for A10, A10s, A13, A20, A31, A31s > > >>> sön 2014-09-28 klockan 02:18 +0200 skrev Luc Verhaegen: > > >>> > > >>> > Why didn't someone from Allwinner send these documents in > > him/herself? > > >>> > > >>> The current person discussion the matter with Allwiner was Simos, who > > is > > >>> part of the linux-sunxi community. Allwinner sent current versions of > > >>> the documents to Simos for distribution in the community. What is > > wrong? > > >>> > > >>> Mailing the full set of documents as attachments directly to the > > >>> mailinglist is not appropriate. And for some strange and unknown > > reason > > >>> Allwinner do not appear to have a public documen
Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
Hi Jacky, I am not sure how these speculations help establishing the open relations all of us are hoping to achieve with Allwinner. Opening sources or giving various pieces of information is often counter-intuitive for various vendors including non-Chineese. Allwinner is making major progress in this respect. Giving us the user manual of the fairly-recent A31/A31s chips is a good example, indeed one that refutes some of your speculations. That said, I believe all of us agree that it is Allwinner's best interest to make its chips popular among developers so that it'll reach, as you say, additional applications beyond tablets. The A80 is a strong chip that can power up a energy-conserving laptop, and the availably of a stable linux is a critical step in making this happen. The Sunxi community is the best way of making this happen. I, for example, am trying to implement various real-time video processing application on Allwinner's SoCs which is a another venue that can take-off both in the academia and the industry. The first vendor who will win the hearts of the open-source community will be the winner in this competition (See for example Atmel in the Arduino versus PIC micro-controllers). I take Kevin's words seriously and expect to see of the manuals of the A80 soon so that all of us will be able to take things forward. All the best, Raanan On Monday, October 13, 2014 6:37:17 PM UTC+3, jacky lau wrote: > > Cover up the bug is just a personal opinion. The more acceptable reason > may be > * They signed a NDA with the IP vendor and can't publish some documents. > * They develop some control unit on the chip, this is private property of > them, so they don't want to open it. Many companies do so, right? > * Open the document will lead to some engineers and marketing guys lost > their job, as the open source community do some work. > I am not a staff of allwinner, so I don't know how they think exactly. > > 在 2014年10月11日星期六UTC+8下午11时15分46秒，Simon Kenyon写道： >> >> On 10/11/14 15:31, jacky lau wrote: >> > A big client will buy thousands of chips once. Are there any relation >> > between big client and user manual publishing? No. So they don't think >> > it's necessary to open their private property. When you are a big >> > client, you are VIP, all document and source code is open to you. And >> > if publish all technical documentation, competitors will know some >> > technical secret (e.g. bug;) they don't want them to know. >> > Open world is beautiful, but they will not actively participateif >> > there is no return. Why some China soc company publish some documents >> > and source code now? I think this is mainly for marketing. But no >> > matter how, VIP priority. >> so the reason why chip manuals are not published is because there are >> bugs in the silicon. gee! who would have thought it. >> at least if we knew what they were we could maybe work around them. >> >> i'm sorry but i don't buy this argument. fear of law suits because of >> patent violations is a more plausible reason. >> > -- 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 and touchscreen/display not working
Hi Pirpi, Please post the following before anyone can help you: 1. linux-sunxi repo HEAD commit 2. your .config file used to build the kernel 3. "lsusb" output 4. "lsmod" output 5. "dmesg | grep usb" output 6. what is your touchpanel kernel module? 7. "dmesg | grep your kernel-module" output 8. "/var/log/Xorg.0.log" file 9. "/usr/share/X11/xorg.conf.d/10-evdev.conf" file -Hunter On Monday, October 13, 2014 4:34:23 AM UTC-5, pirpi srd wrote: > > Hi all, > > I have a pcduino3 board. I have built the livesuit image for it, but after > installing OS completely following the procedure given to burn it to NAND, > the USB port and the touchscreen/display are not working. Could any one > help me in this regard. I downloaded the a20-kernel from your repository. > > Thanks, > pirpi > -- 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] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
Cover up the bug is just a personal opinion. The more acceptable reason may be * They signed a NDA with the IP vendor and can't publish some documents. * They develop some control unit on the chip, this is private property of them, so they don't want to open it. Many companies do so, right? * Open the document will lead to some engineers and marketing guys lost their job, as the open source community do some work. I am not a staff of allwinner, so I don't know how they think exactly. 在 2014年10月11日星期六UTC+8下午11时15分46秒，Simon Kenyon写道： > > On 10/11/14 15:31, jacky lau wrote: > > A big client will buy thousands of chips once. Are there any relation > > between big client and user manual publishing? No. So they don't think > > it's necessary to open their private property. When you are a big > > client, you are VIP, all document and source code is open to you. And > > if publish all technical documentation, competitors will know some > > technical secret (e.g. bug;) they don't want them to know. > > Open world is beautiful, but they will not actively participateif > > there is no return. Why some China soc company publish some documents > > and source code now? I think this is mainly for marketing. But no > > matter how, VIP priority. > so the reason why chip manuals are not published is because there are > bugs in the silicon. gee! who would have thought it. > at least if we knew what they were we could maybe work around them. > > i'm sorry but i don't buy this argument. fear of law suits because of > patent violations is a more plausible reason. > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
I agree with you and Jhon Yi. Developing a soc is not too hard now, getting customers is harder and more important. I hope the market will force all China Soc company more open. But before that happen, I don't think they will become more open. They don't have experience in working with the open source community, if you want them to be more open, you need to do more communicate with them. And remember, to them, neither the law nor the spirit of free software, but making money is paramount. Tell them they will get more customers, make more money and prove it, then they will follow. 在 2014年10月11日星期六UTC+8下午10时53分48秒，Jon Smirl写道： > > On Sat, Oct 11, 2014 at 10:31 AM, jacky lau > wrote: > > A big client will buy thousands of chips once. Are there any relation > > between big client and user manual publishing? No. So they don't think > it's > > necessary to open their private property. When you are a big client, you > are > > VIP, all document and source code is open to you. And if publish all > > technical documentation, competitors will know some technical secret > (e.g. > > bug;) they don't want them to know. > > Open world is beautiful, but they will not actively participate if there > is > > no return. Why some China soc company publish some documents and source > code > > now? I think this is mainly for marketing. But no matter how, VIP > priority. > > Right now Allwinner is only good for tablets and STBs because > Allwinner supplies turnkey solutions. If documentation were more open > other applications could be developed. If customer can't get software > working for these other applications, they won't buy thousands of > chips. So if Allwinner wants to survive past the end of the tablet fad > they have to start developing these other markets. Otherwise when the > tablet fad is over it will be the end of Allwinner. > > You also over estimate the value of "technical secrets". What is the > point of putting a secret h.264 encode/decode unit on the chip if half > of your customers can't get it working? Obviously Rockchip knows how > to make h.264 encode/decode since they have a similar unit on their > chip. And so does Freescale, TI, ST, etc. -- there is no big secret in > making h.264 hardware for people familiar with how to do it (hint, it > is an ISO standard). So by keeping the documentation secret you hide > nothing significant from your competitors and much, much worse -- you > keep your own customers from using the hardware they bought. Think > about it --- which is more important - hiding something form a > competitor that they probably already know, or getting your customers > to ship and buy more chips? > > Bottom line - which one brings cash in the door - secret documentation > or getting as many customers as possible to ship? > > > > > > 在 2014年10月6日星期一UTC+8下午8时55分30秒，RFat写道： > >> > >> Hi Kevin, > >> > >> Publishing the user manuals will certainly increase Allwinner's chips > >> popularity. > >> > >> I was wondering if there is a rough estimate as to when the A80's > manual > >> will be made available? > >> > >> Thanks! > >> Raanan > >> > >> On Monday, September 29, 2014 12:46:53 PM UTC+3, > ke...@allwinnertech.com > >> wrote: > >>> > >>> Hi All, > >>> > >>> I have put the documents on github, and the url is > >>> https://github.com/allwinner-zh/documents.git > >>> Thanks Simos, Henrik and Luc's suggestion. And other documents will be > >>> upated to here when released. > >>> > >>> > >>> > >>> Best Regards, > >>> kevin.z.m > >>> > >>> > >>> > >>> From: HenrikNordström > >>> Date: 2014-09-29 08:46 > >>> To: linux...@googlegroups.com > >>> CC: sh...@allwinnertech.com; Meng Zhang > >>> Subject: Re: [linux-sunxi] Allwinner documentation (hardware > datasheet, > >>> user manual) for A10, A10s, A13, A20, A31, A31s > >>> sön 2014-09-28 klockan 02:18 +0200 skrev Luc Verhaegen: > >>> > >>> > Why didn't someone from Allwinner send these documents in > him/herself? > >>> > >>> The current person discussion the matter with Allwiner was Simos, who > is > >>> part of the linux-sunxi community. Allwinner sent current versions of > >>> the documents to Simos for distribution in the community. What is > wrong? > >>> > >>> Mailing the full set of documents as attachments directly to the > >>> mailinglist is not appropriate. And for some strange and unknown > reason > >>> Allwinner do not appear to have a public document archive for this > kind > >>> of documents themselves, and seems to only distribute them via email > to > >>> their customers when requested. > >>> > >>> The real question is why AW do not make the documents available in > >>> public themselves, and likewise why they do not have a public git > >>> repository for SDK sources etc (github or elsewhere). > >>> > >>> Regards > >>> Henrik > >>> > >>> > >>> NOTICE: This e-mail and any included attachments a
[linux-sunxi] Re: [PATCH 6/9] ARM: sunxi: Add support for R_PIO gpio banks
On Sun, Oct 12, 2014 at 04:23:05PM +0800, Chen-Yu Tsai wrote: > On Sun, Oct 12, 2014 at 12:05 AM, Ian Campbell wrote: > > On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote: > >> From: Hans de Goede > >> > >> The A31, A23 and later SoCs have an extra pin controller, called CPUs_PIO > >> or R_PIO, which handles pin banks L and beyond. > > > > Does it also have enough space for 9 banks? Since you overlay a struct > > sunxi_gpio_reg on it which has a gpio_bank[SUNXI_GPIO_BANKS] over it. > > Yes it does, as seen in the latest A31 manuals released by Allwinner. > > > SUNXI_GPIO_BANKS is now also confusingly named since it is really > > "number of banks on the first/original GPIO controller". Eventually > > someone will use it as the actual total and be very sad. > > > > I think it might be best if we retcon some distinct name onto the > > original GPIO controller so we can have SUNXIO_GPIO_BLA_BANKS and > > SUNXI_GPIO_R_BANKS (or even just call them controller 0 and 1 and have > > SUNXI_GPIO0_BANKS and SUNXI_GPIO1_BANKS, if that's not too confusing) > > The latest manuals have "CPUx-PORT" and "CPUs-PORT" for the respective > chapters. I'm guessing "x" is for 0~3 cores, and s is for standby or > something. iirc, it was meant for "special". > > Of course it's also confusing that Allwinner's sources use the "R_" > prefix for all hardware in that address range, while the datasheet > lists the GPIO function names as "s_something". We use the same pin convention than in the datasheet in mainline (but starting from PL for the special pins). And it's true that we do prefix all the functions by s_, once again, just like the datasheet does. The fact that it comes from a different controller is only expressed by where the pinctrl pins node is defined in the DT. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] [PATCH u-boot-sunxi] sunxi: axp152: dcdc3 scale is 50mV / step not
Hi All, This patch fixes a regression introduced by the axp code cleanups did a while back. The regression causes the DRAM voltage to be set to 2.3V instead of 1.5V, this patch fixes this. Please apply this to linux-sunxi/u-boot-sunxi ASAP. 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 u-boot-sunxi] sunxi: axp152: dcdc3 scale is 50mV / step not 25mV / step
Currently uboot wrongly uses 25mV / step for dcdc3, this is a copy and paste
error introduced when adding the axp152_mvolt_to_target during review of the
axp152.c driver. This results in u-boot setting Vddr to 2.3V instead of 1.5V.
This commit fixes this.
Signed-off-by: Hans de Goede
---
drivers/power/axp152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/axp152.c b/drivers/power/axp152.c
index fa4ea05..27c2c4c 100644
--- a/drivers/power/axp152.c
+++ b/drivers/power/axp152.c
@@ -62,7 +62,7 @@ int axp152_set_dcdc2(int mvolt)
int axp152_set_dcdc3(int mvolt)
{
- u8 target = axp152_mvolt_to_target(mvolt, 700, 3500, 25);
+ u8 target = axp152_mvolt_to_target(mvolt, 700, 3500, 50);
return axp152_write(AXP152_DCDC3_VOLTAGE, target);
}
--
2.1.0
--
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: Cedarx hardware decoder not supporting dual display video output.
Hi All, with this branch, https://github.com/mittorn/libvdpau-sunxi some improvements. with export VDPAU_SCREEN=0 i am getting video in HDMI. with export VDPAU_SCREEN=1 i am getting video in TV. But i want on both. can any one tell me what need to change in code. Regards Punith -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 3.4] sunxi: Calculate PLL5P clock divisors for G2D, ACE and DEBE
Hi,
On 10/04/2014 07:53 AM, Siarhei Siamashka wrote:
> When PLL5P is used as a parent clock for some of the peripherals,
> the current code just selects some hardcoded divisors. This happens
> to work, but only under assumption that the PLL5P clock speed is
> somewhere between 360MHz and 480MHz (the typical DRAM clock speeds).
>
> However with some tweaks for the DRAM parameters, it is possible to
> clock DRAM up to 600MHz and more on some devices:
>
> http://lists.denx.de/pipermail/u-boot/2014-July/183981.html
>
> And this introduces concerns about the hardcoded divisors in the
> kernel, which may cause some peripherals to operate at abnormally
> high clock speeds if the PLL5 clock speed is too fast (PLL5 is used
> for clocking DRAM).
>
> Moreover, it makes sense to avoid pre-dividing PLL5P and make it run
> even faster than DRAM. This provides better granularity of the clock
> speed selection for MBUS, G2D and everything else that is using PLL5P
> as the parent clock. but running PLL5P faster means that the hardcoded
> divisors become even more inappropriate.
>
> This patch improves the clock divisors selection for G2D, ACE and
> DEBE to insure that they can work correctly with any PLL5P clock
> speed.
>
> Signed-off-by: Siarhei Siamashka
Looks good:
Acked-by: Hans de Goede
Can we please get this merged, I'm working on getting the sunxi-3.4 kernels
to work with upstream u-boot, so that we can stop maintaining our own fork,
and this is necessary for this.
Regards,
Hans
> ---
> drivers/char/sunxi_g2d/g2d.c| 8 ++--
> drivers/media/audio/sun4i_dev_ace.c | 7 ++-
> drivers/video/sunxi/disp/disp_clk.c | 17 -
> 3 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/char/sunxi_g2d/g2d.c b/drivers/char/sunxi_g2d/g2d.c
> index 288685a..539c726 100644
> --- a/drivers/char/sunxi_g2d/g2d.c
> +++ b/drivers/char/sunxi_g2d/g2d.c
> @@ -29,9 +29,12 @@
> struct clk *g2d_ahbclk,*g2d_dramclk,*g2d_mclk,*g2d_src;
> extern __g2d_drv_tg2d_ext_hd;
>
> +/* Arbitrarily pick 240MHz (TODO: confirm what is the real limit) */
> +#define G2D_CLOCK_SPEED_LIMIT 24000
> +
> int g2d_openclk(void)
> {
> - __u32 ret;
> + __u32 ret, g2d_div;
>
> /* ahb g2d gating */
> g2d_ahbclk = clk_get(NULL,"ahb_de_mix");
> @@ -51,7 +54,8 @@ int g2d_openclk(void)
> clk_put(g2d_src);
>
> ret = clk_get_rate(g2d_src);
> - clk_set_rate(g2d_mclk,ret/2);
> + g2d_div = DIV_ROUND_UP(ret, G2D_CLOCK_SPEED_LIMIT);
> + clk_set_rate(g2d_mclk, ret / g2d_div);
>
> return 0;
> }
> diff --git a/drivers/media/audio/sun4i_dev_ace.c
> b/drivers/media/audio/sun4i_dev_ace.c
> index 59fdfeb..e3599f6 100644
> --- a/drivers/media/audio/sun4i_dev_ace.c
> +++ b/drivers/media/audio/sun4i_dev_ace.c
> @@ -91,10 +91,14 @@ static irqreturn_t ace_interrupt(int irq, void *dev)
> return IRQ_HANDLED;
> }
>
> +/* 200MHz is the limit for ACE_CLK_REG (see the A10 User Manual) */
> +#define ACE_CLOCK_SPEED_LIMIT 2
> +
> static long ace_dev_ioctl(struct file *filp, unsigned int cmd, unsigned long
> arg)
> {
> int ret_val = 0;
> unsigned long test_arg;
> + int pll5_div;
> __ace_req_e mpara;
> unsigned long rate;
> switch (cmd){
> @@ -137,7 +141,8 @@ static long ace_dev_ioctl(struct file *filp, unsigned int
> cmd, unsigned long arg
> printk("try to set parent of ace_moduleclk to
> ace_pll5clk failed!\n");
> }
> rate = clk_get_rate(ace_pll5_pclk);
> - if(clk_set_rate(ace_moduleclk, rate/2)) {
> + pll5_div = DIV_ROUND_UP(rate, ACE_CLOCK_SPEED_LIMIT);
> + if(clk_set_rate(ace_moduleclk, rate / pll5_div)) {
> printk("try to set ace_moduleclk rate
> failed!!!\n");
>goto out;
> }
> diff --git a/drivers/video/sunxi/disp/disp_clk.c
> b/drivers/video/sunxi/disp/disp_clk.c
> index abd1877..ff46bcc 100644
> --- a/drivers/video/sunxi/disp/disp_clk.c
> +++ b/drivers/video/sunxi/disp/disp_clk.c
> @@ -120,9 +120,12 @@ __disp_clk_tab clk_tab = {
> }
> };
>
> +/* 300MHz */
> +#define DEBE_CLOCK_SPEED_LIMIT 3
> +
> __s32 image_clk_init(__u32 sel)
> {
> - __u32 dram_pll;
> + __u32 dram_pll, pll5_div;
>
> if (sel == 0) {
> h_debe0ahbclk = OSAL_CCMU_OpenMclk(AW_MOD_CLK_AHB_DEBE0);
> @@ -137,10 +140,8 @@ __s32 image_clk_init(__u32 sel)
> OSAL_CCMU_SetMclkSrc(h_debe0mclk, AW_SYS_CLK_PLL5P);
>
> dram_pll = OSAL_CCMU_GetSrcFreq(AW_SYS_CLK_PLL5P);
> - if (dram_pll < 3)
> - OSAL_CCMU_SetMclkDiv(h_debe0mclk, 1);
> - else
> - OSAL_CCMU_SetMclkDiv(h_debe0mclk, 2);
> + pll5_div = DIV_ROUND_UP(dram_pll, DEBE_C
Re: [linux-sunxi] [PATCH 3.4] sunxi: axp209: Protect dcdc3 voltage from modification
Hi,
On 10/04/2014 07:53 AM, Siarhei Siamashka wrote:
> The dcdc3 voltage is expected to be set by the bootloader and the right
> voltage depends on the DRAM settings (higher clock speed needs more
> voltage). Allowing to use the 'dcdc3_vol' parameter from the FEX file
> only introduces an unnecessary fragile dependency between the settings
> in u-boot and the settings in FEX. So now we ignore this parameter in
> FEX and keep the original dcdc3 voltage set by the bootloader.
>
> The dmesg log now looks like this:
>
> [2.212941] axp20_ldo1: 1300 mV
> [2.221370] axp20_ldo2: 1800 <--> 3300 mV at 3000 mV
> [2.231662] axp20_ldo3: 700 <--> 3500 mV at 2800 mV
> [2.241747] axp20_ldo4: 1250 <--> 3300 mV at 2800 mV
> [2.251906] axp20_buck2: 700 <--> 2275 mV at 1400 mV
> [2.263430] somebody is trying to set dcdc3 range to (130, 130) uV
> [2.275327] but we keep dcdc3 = 125 uV from the bootloader
> [2.285406] axp20_buck3: 700 <--> 3500 mV at 1250 mV
> [2.295299] axp20_ldoio0: 1800 <--> 3300 mV at 2800 mV
>
> Signed-off-by: Siarhei Siamashka
Looks good:
Acked-by: Hans de Goede
Can we please get this merged, I'm working on getting the sunxi-3.4 kernels
to work with upstream u-boot, so that we can stop maintaining our own fork,
and this is necessary for this.
Regards,
Hans
> ---
> drivers/power/axp_power/axp20-regu.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/axp_power/axp20-regu.c
> b/drivers/power/axp_power/axp20-regu.c
> index e56c5f5..30ceb5c 100644
> --- a/drivers/power/axp_power/axp20-regu.c
> +++ b/drivers/power/axp_power/axp20-regu.c
> @@ -37,6 +37,7 @@ static inline int check_range(struct axp_regulator_info
> *info,
> return 0;
> }
>
> +static int axp_get_voltage(struct regulator_dev *rdev);
>
> /* AXP common operations */
> static int axp_set_voltage(struct regulator_dev *rdev, int min_uV, int
> max_uV,
> @@ -45,7 +46,14 @@ static int axp_set_voltage(struct regulator_dev *rdev, int
> min_uV, int max_uV,
> struct axp_regulator_info *info = rdev_get_drvdata(rdev);
> struct device *axp_dev = to_axp_dev(rdev);
> uint8_t val, mask;
> -
> +
> + if (rdev_get_id(rdev) == AXP20_ID_BUCK3) {
> + pr_err("somebody is trying to set dcdc3 range to (%d, %d) uV\n",
> + min_uV, max_uV);
> + pr_err("but we keep dcdc3 = %d uV from the bootloader\n",
> + axp_get_voltage(rdev));
> + return 0;
> + }
>
> if (check_range(info, min_uV, max_uV)) {
> pr_err("invalid voltage range (%d, %d) uV\n", min_uV, max_uV);
>
--
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 0/7] clk: sun6i: Unify AHB1 clock and fix rate calculation
On Thu, Oct 09, 2014 at 11:16:50AM +0800, Chen-Yu Tsai wrote: > On Sat, Sep 27, 2014 at 2:53 AM, Mike Turquette wrote: > > Quoting Chen-Yu Tsai (2014-09-25 17:55:27) > >> On Fri, Sep 26, 2014 at 8:25 AM, Mike Turquette > >> wrote: > >> > Quoting Maxime Ripard (2014-09-11 13:36:23) > >> >> Hi Chen-Yu, > >> >> > >> >> On Sat, Sep 06, 2014 at 06:47:21PM +0800, Chen-Yu Tsai wrote: > >> >> > Hi everyone, > >> >> > > >> >> > This series unifies the mux and divider parts of the AHB1 clock found > >> >> > on sun6i and sun8i, while also adding support for the pre-divider on > >> >> > the PLL6 input. > >> >> > > >> >> > The rate calculation logic must factor in which parent it is using to > >> >> > calculate the rate, to decide whether to use the pre-divider or not. > >> >> > This is beyond the original factors clk design in sunxi. To avoid > >> >> > feature bloat, this is implemented as a seperate composite clk. > >> >> > > >> >> > The new clock driver is registered with a separate OF_CLK_DECLARE. > >> >> > This is done so that assigned-clocks* properties on the clk provider > >> >> > node can actually work. The clock framework arranges the clock setup > >> >> > order by checking whether all clock parents are available, by checking > >> >> > the node matching OF_CLK_DECLARE. > >> >> > > >> >> > However, the sunxi clk driver is based on the root node compatible, > >> >> > has no defined dependencies (parents), and is setup before the > >> >> > fixed-rate > >> >> > clocks. Thus when the ahb1 clock is added, all parents have rate = 0. > >> >> > There is no way to calculate the required clock factors to set a > >> >> > default > >> >> > clock rate under these circumstances. This happens when we set the > >> >> > defaults in the clock node (provider), rather than a clock consumer. > >> >> > > >> >> > I can think of 2 ways to solve the dependency issue, but neither is > >> >> > pretty. One would be to move the root fixed-rate clocks into the sunxi > >> >> > clk driver. The other would be separating all the clocks into > >> >> > individual > >> >> > OF_CLK_DECLARE statements, which adds a lot of boilerplate code. > >> >> > >> >> I don't know what Mike thinks of this, but I'd prefer the second. > >> > > >> > I do not fully understand the problem. Ideally the clock driver should > >> > have some way to fail with EPROBE_DEFER until the fixed-rate clocks are > >> > registered. Those fixed-rate parents are enumerated in your dts, right? > >> > Why isn't this enough? > >> > >> This is due to the way the sunxi clock driver is setup. The clock driver's > >> OF_CLK_DECLARE matches against the "soc" node, not the individual clock > >> nodes. When the setup function is called, it just registers all the > >> supported clocks. There are no dependencies listed. > >> > >> Unfortunately, the fixed-factor clock is in the middle of the whole clock > >> tree. The sunxi clock driver provides its parents _and_ its children. > >> Naturally the clock framework then probes the fixed-factor clock after > >> the sunxi ones. Any attempts to change the state of clocks under the > >> unavailable fixed-factor clock, such as done by of_clk_set_defaults(), > >> would get an incomplete clock, likely with no parents and parent_rate = 0. > >> That is until of_clk_init() finishes and all clocks are properly hooked > >> up. > >> > >> Anyway, this problem only occurred when I added clk-assigned-* defaults > >> to the clock provider node, which is not the case anymore. > > > > Makes sense. I guess you could ignore the problem until you need to use > > the assigned defaults. > > An update on this. Improper ordering of clock probing also affects > sunxi's clock protection code. > > Currently we have 2 mechanisms for protecting clocks. > > a) A list of clock names in sunxi/clk-sunxi.c, fetched and enabled > using clkdev. > b) Enabling clocks right after they are registered. Used for separated > clock drivers like sun5i-a13-mbus and sun8i-a23-mbus. > > One issue I ran across was when most of the clock tree is registered using > independent CLK_OF_DECLAREs, as I'm doing for the A80, if the protected > clocks list is handled before the clock tree is complete, the prepare > and enable calls are not correctly propagated to the parents that arrive > later on. > > This happens to the ahb*_sdram gates. I guess that eventually, we should be able to remove a). For the time being, maybe we can just move the clock protection code itself to a later initcall? -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] [PATCH 2/2 3.4] Cleanup sun7i_defconfig based on sun4i_defconfig.
From: rellla --- arch/arm/configs/sun7i_defconfig | 1038 +++--- 1 file changed, 69 insertions(+), 969 deletions(-) diff --git a/arch/arm/configs/sun7i_defconfig b/arch/arm/configs/sun7i_defconfig index 455ebcc..be7fedb 100644 --- a/arch/arm/configs/sun7i_defconfig +++ b/arch/arm/configs/sun7i_defconfig @@ -7,8 +7,6 @@ CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y -CONFIG_IRQ_DOMAIN_DEBUG=y -CONFIG_RCU_FAST_NO_HZ=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=19 @@ -18,20 +16,12 @@ CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y -CONFIG_CGROUP_MEM_RES_CTLR=y -CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y -CONFIG_CGROUP_MEM_RES_CTLR_KMEM=y -CONFIG_CGROUP_PERF=y -CONFIG_CGROUP_SCHED=y -CONFIG_CFS_BANDWIDTH=y -CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGROUP=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_KALLSYMS_ALL=y CONFIG_PERF_COUNTERS=y # CONFIG_COMPAT_BRK is not set -CONFIG_JUMP_LABEL=y CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y @@ -52,30 +42,18 @@ CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_ARCH_SUN7I=y -# CONFIG_CACHE_L2X0 is not set +CONFIG_SWP_EMULATE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y -CONFIG_SMP=y -CONFIG_ARM_ARCH_TIMER=y -CONFIG_NR_CPUS=2 CONFIG_PREEMPT=y CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set CONFIG_HIGHMEM=y CONFIG_COMPACTION=y CONFIG_KSM=y -CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/mmc0p1 rw init=/init loglevel=8" -CONFIG_KEXEC=y +CONFIG_CMDLINE="mem=448M@0x4000 console=ttyS0,115200" CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_STAT=m -CONFIG_CPU_FREQ_DEFAULT_GOV_FANTASY=y -CONFIG_CPU_FREQ_GOV_PERFORMANCE=y -CONFIG_CPU_FREQ_GOV_POWERSAVE=m -CONFIG_CPU_FREQ_GOV_USERSPACE=m -CONFIG_CPU_FREQ_GOV_ONDEMAND=y -CONFIG_CPU_FREQ_GOV_INTERACTIVE=y -CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m -CONFIG_CPU_FREQ_USR_EVNT_NOTIFY=y +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPU_FREQ_DVFS=y CONFIG_CPU_IDLE=y CONFIG_VFP=y @@ -83,298 +61,41 @@ CONFIG_NEON=y CONFIG_BINFMT_MISC=y CONFIG_PM_RUNTIME=y CONFIG_PM_DEBUG=y +CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM_USER=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y -CONFIG_IP_ADVANCED_ROUTER=y -CONFIG_IP_FIB_TRIE_STATS=y -CONFIG_IP_MULTIPLE_TABLES=y -CONFIG_IP_ROUTE_MULTIPATH=y -CONFIG_IP_ROUTE_VERBOSE=y -CONFIG_IP_PNP=y -CONFIG_IP_PNP_DHCP=y -CONFIG_IP_PNP_BOOTP=y -CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=y -CONFIG_NET_IPGRE_DEMUX=m -CONFIG_NET_IPGRE=m -CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y -CONFIG_IP_MROUTE_MULTIPLE_TABLES=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y -CONFIG_ARPD=y CONFIG_SYN_COOKIES=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y -CONFIG_INET_DIAG=m -CONFIG_INET_UDP_DIAG=m -CONFIG_TCP_CONG_ADVANCED=y -CONFIG_TCP_CONG_BIC=y -CONFIG_TCP_CONG_WESTWOOD=y -CONFIG_TCP_CONG_HTCP=y -CONFIG_TCP_CONG_HSTCP=y -CONFIG_TCP_CONG_HYBLA=y -CONFIG_TCP_CONG_SCALABLE=y -CONFIG_TCP_CONG_LP=y -CONFIG_TCP_CONG_VENO=y -CONFIG_TCP_CONG_YEAH=y -CONFIG_TCP_CONG_ILLINOIS=y -CONFIG_TCP_MD5SIG=y -CONFIG_IPV6=y -CONFIG_IPV6_PRIVACY=y -CONFIG_IPV6_ROUTER_PREF=y -CONFIG_IPV6_ROUTE_INFO=y -CONFIG_IPV6_OPTIMISTIC_DAD=y -CONFIG_INET6_AH=m -CONFIG_INET6_ESP=m -CONFIG_INET6_IPCOMP=m -CONFIG_IPV6_MIP6=m -CONFIG_INET6_XFRM_MODE_TRANSPORT=m -CONFIG_INET6_XFRM_MODE_TUNNEL=m -CONFIG_INET6_XFRM_MODE_BEET=m -CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m -CONFIG_IPV6_SIT=m -CONFIG_IPV6_SIT_6RD=y -CONFIG_IPV6_TUNNEL=m -CONFIG_IPV6_MULTIPLE_TABLES=y -CONFIG_IPV6_SUBTREES=y -CONFIG_IPV6_MROUTE=y -CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y -CONFIG_IPV6_PIMSM_V2=y +# CONFIG_INET_DIAG is not set +# CONFIG_IPV6 is not set # CONFIG_ANDROID_PARANOID_NETWORK is not set CONFIG_NETWORK_SECMARK=y -CONFIG_NETWORK_PHY_TIMESTAMPING=y -CONFIG_NETFILTER=y -CONFIG_NF_CONNTRACK=m -CONFIG_NF_CONNTRACK_SECMARK=y -CONFIG_NF_CONNTRACK_ZONES=y -CONFIG_NF_CONNTRACK_EVENTS=y -CONFIG_NF_CONNTRACK_TIMEOUT=y -CONFIG_NF_CONNTRACK_TIMESTAMP=y -CONFIG_NF_CT_PROTO_DCCP=m -CONFIG_NF_CT_PROTO_SCTP=m -CONFIG_NF_CT_PROTO_UDPLITE=m -CONFIG_NF_CONNTRACK_AMANDA=m -CONFIG_NF_CONNTRACK_FTP=m -CONFIG_NF_CONNTRACK_H323=m -CONFIG_NF_CONNTRACK_IRC=m -CONFIG_NF_CONNTRACK_NETBIOS_NS=m -CONFIG_NF_CONNTRACK_SNMP=m -CONFIG_NF_CONNTRACK_PPTP=m -CONFIG_NF_CONNTRACK_SANE=m -CONFIG_NF_CONNTRACK_SIP=m -CONFIG_NF_CONNTRACK_TFTP=m -CONFIG_NF_CT_NETLINK=m -CONFIG_NF_CT_NETLINK_TIMEOUT=m -CONFIG_NETFILTER_TPROXY=m -CONFIG_NETFILTER_XT_SET=m -CONFIG_NETFILTER_XT_TARGET_AUDIT=m -CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m -CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m -CONFIG_NETFILTER_XT_TARGET_CONNMARK=m -CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m -CONFIG_NETFILTER_XT_TARGET_CT=m -CONFIG_NETFILTER_XT_TARGET_DSCP=m -CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m -CONFIG_NETFILTER_XT_TARGET_LED=m -CONFIG_NETFILTER_XT_TARGET_LOG=m -CONFIG_NETFILTER_XT_TARGET_MARK=m -CONFIG_NETFILTER_XT_TARGET_NFLOG=m -CONFIG_NETFIL
[linux-sunxi] [PATCH 0/2 3.4] defconfigs: Fix sun4i-defconfig and sun7i_defconfig
From: rellla rellla (2): Sunxi SATA driver should be built in-kernel in order to allow root filesystems on sata per default. Cleanup sun7i_defconfig based on sun4i_defconfig. arch/arm/configs/sun4i_defconfig |2 +- arch/arm/configs/sun7i_defconfig | 1038 +++--- 2 files changed, 70 insertions(+), 970 deletions(-) -- 2.1.1 -- 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/2 3.4] Sunxi SATA driver should be built in-kernel in order to allow root filesystems on sata per default.
From: rellla --- arch/arm/configs/sun4i_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/sun4i_defconfig b/arch/arm/configs/sun4i_defconfig index 4e6f9fc..06b6fa6 100644 --- a/arch/arm/configs/sun4i_defconfig +++ b/arch/arm/configs/sun4i_defconfig @@ -115,7 +115,7 @@ CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SCSI_MULTI_LUN=y CONFIG_ATA=y CONFIG_SATA_AHCI_PLATFORM=y -CONFIG_SW_SATA_AHCI_PLATFORM=m +CONFIG_SW_SATA_AHCI_PLATFORM=y CONFIG_NETDEVICES=y CONFIG_SUNXI_EMAC=y CONFIG_PHYLIB=y -- 2.1.1 -- 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] USB and touchscreen/display not working
Hi all, I have a pcduino3 board. I have built the livesuit image for it, but after installing OS completely following the procedure given to burn it to NAND, the USB port and the touchscreen/display are not working. Could any one help me in this regard. I downloaded the a20-kernel from your repository. Thanks, pirpi -- 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] sunxi-boards: a20-cubieboard2, a20-cubietruck: Fix ir GPIO
From: rellla Parameter ir_rx must be called ir0_rx. Otherwise no input is recognized. Signed-off-by: rellla --- sys_config/a20/cubieboard2.fex | 2 +- sys_config/a20/cubietruck.fex | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sys_config/a20/cubieboard2.fex b/sys_config/a20/cubieboard2.fex index c8c9c74..ade2f83 100644 --- a/sys_config/a20/cubieboard2.fex +++ b/sys_config/a20/cubieboard2.fex @@ -888,7 +888,7 @@ leds_trigger_2 = "heartbeat" [ir_para] ir_used = 1 -ir_rx = port:PB04<2> +ir0_rx = port:PB04<2> [pmu_para] pmu_used = 1 diff --git a/sys_config/a20/cubietruck.fex b/sys_config/a20/cubietruck.fex index 5d7f085..7f8ec02 100644 --- a/sys_config/a20/cubietruck.fex +++ b/sys_config/a20/cubietruck.fex @@ -874,7 +874,7 @@ switch_used = 1 [ir_para] ir_used = 1 -ir_rx = port:PB04<2> +ir0_rx = port:PB04<2> [pmu_para] pmu_used = 1 -- 2.1.1 -- 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 v3 0/6] sunxi: Enable second sdcard slot found on some boards
On Mon, 2014-10-13 at 06:48 +0200, Hans de Goede wrote: > Hi, > > On 10/12/2014 11:19 PM, Ian Campbell wrote: > > On Sun, 2014-10-12 at 20:07 +0200, Hans de Goede wrote: > >> Hi Ian, > >> > >> Here is v3 of my second sdcard slot patch-set. > >> > >> Changes since v2: > >> - Rebased on top of latest u-boot-sunxi-next > >> - Fixed Kconfig help text for : "sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a > >> proper Kconfig option" to also mention mmc1 > >> - Added checks for sunxi_mmc_init failing to: "sunxi: When we've both mmc0 > >> and mmc2, detect from which one we're booting" > >> - Added a 6th patch with my version of the Kconfig unification, to avoid > >> you needing to rebase yours. > >> > >> I believe this patch is ready to go upstream now, so if I can have your > >> Acked-by for patches 3 and 6, then I'll push this to next, or you can push > >> this to next yourself. > > > > All Acked. I'm not going to commit tonight and I'm on trains all day > > tomorrow (heading to Düsseldorf), unless I hear otherwise I'll assume > > you are doing it. > > Done. > > And good to hear that you're heading over to Dusseldorf too. I'll be at the > u-boot mini-summit the entire day today (currently in the train towards > Dusseldorf). We definitely should get together, even if just to say hi :) Absolutely. I'm in town all week for LPC and plumbers. > Maybe I'll see you at the u-boot mini-summit ? If you cannot make it, > maybe you can make the u-boot dinner tonight ? : I should be arriving not long after 5, so I think it's doubtful I'll make the mini-summit, with finding my hotel etc. I didn't know about the evening bit, now that I do I'll try and make it down. Ian. > > http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 > > 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.
