Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Tue, May 12, 2015 at 04:27:59PM +0200, Maxime Ripard wrote: > On Mon, Apr 27, 2015 at 07:07:28PM +0100, Mark Brown wrote: > > Probably best, the Pi bootloader does make it a bit more important. > > Might also be worth speaking to Greg though. > So, do you want me to resend that patch and discuss this directly > there (with Greg in Cc) ? Sounds like a good first step. -- 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
[linux-sunxi] Re: [PATCH 1/2] ARM: dts: sun9i: cubieboard4: Enable USB support
On Tue, May 12, 2015 at 10:57 PM, Maxime Ripard
wrote:
> On Mon, May 11, 2015 at 04:26:58PM +0800, Chen-Yu Tsai wrote:
>> >> >> +&usbphy1 {
>> >> >> + phy-supply = <®_usb1_vbus>;
>> >> >> + status = "okay";
>> >> >> +};
>> >> >> +
>> >> >> +/*
>> >> >> + * Unfortunately reg_usb1_vbus also powers one of the ports from
>> >> >> usb3's hub.
>> >> >> + * One should always make sure both regulators are enabled and
>> >> >> working for
>> >> >> + * all USB ports to have power.
>> >> >> + */
>> >> >
>> >> > Can't we just provide the two regulators, and enable both of them so
>> >> > that we know that we always have the needed regulators enabled,
>> >> > disregarding which USB port is used?
>> >>
>> >> Would setting "always-on" for both regulators work for you?
>> >> Or maybe just the one that's used by both USB hosts?
>> >
>> > I was more thinking of giving to the phy an additional regulator, so
>> > that it would enable both the regulators needed to power up all ports.
>>
>> That would require adding back all the regulator-related code I
>> removed from the phy driver before it was merged. (sigh) It's not
>> like the regulator bindings takes a list.
>
> Yeah, but maybe we can just add an optional device-supply property or
> something like that to power up the devices connected on the bus.
(CC-ed Kishon)
Do we think this generic enough to go into the generic phy core?
>> I see this as more of a hardware design flaw, and we should label
>> it as such.
>
> This can be seen as one, and we can debate it for some time I guess,
> but if the hardware guys were not making crazy stuff like that, we
> would run out of work pretty quickly :)
Ah yes, but the users would be happier. :)
> What we really need to do is find a proper and reliable way to handle
> this case. Whether we declare it as a flaw or not is a separate
> debate.
>
>> And it might still work for self-powered devices even if VBUS is
>> off. The USB hub chip is always on.
>
> That still leaves a significant amount of devices out and non
> functional, especially very standard devices like USB keys, keyboards
> or headsets that you would expect to just work.
I agree. So the question is where should this go in.
ChenYu
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/2] ARM: dts: sun9i: cubieboard4: Enable USB support
On Mon, May 11, 2015 at 04:26:58PM +0800, Chen-Yu Tsai wrote:
> >> >> +&usbphy1 {
> >> >> + phy-supply = <®_usb1_vbus>;
> >> >> + status = "okay";
> >> >> +};
> >> >> +
> >> >> +/*
> >> >> + * Unfortunately reg_usb1_vbus also powers one of the ports from
> >> >> usb3's hub.
> >> >> + * One should always make sure both regulators are enabled and working
> >> >> for
> >> >> + * all USB ports to have power.
> >> >> + */
> >> >
> >> > Can't we just provide the two regulators, and enable both of them so
> >> > that we know that we always have the needed regulators enabled,
> >> > disregarding which USB port is used?
> >>
> >> Would setting "always-on" for both regulators work for you?
> >> Or maybe just the one that's used by both USB hosts?
> >
> > I was more thinking of giving to the phy an additional regulator, so
> > that it would enable both the regulators needed to power up all ports.
>
> That would require adding back all the regulator-related code I
> removed from the phy driver before it was merged. (sigh) It's not
> like the regulator bindings takes a list.
Yeah, but maybe we can just add an optional device-supply property or
something like that to power up the devices connected on the bus.
> I see this as more of a hardware design flaw, and we should label
> it as such.
This can be seen as one, and we can debate it for some time I guess,
but if the hardware guys were not making crazy stuff like that, we
would run out of work pretty quickly :)
What we really need to do is find a proper and reliable way to handle
this case. Whether we declare it as a flaw or not is a separate
debate.
> And it might still work for self-powered devices even if VBUS is
> off. The USB hub chip is always on.
That still leaves a significant amount of devices out and non
functional, especially very standard devices like USB keys, keyboards
or headsets that you would expect to just work.
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] [PATCH 2/3] spidev: Add DT binding example.
Hello, On 12 May 2015 at 16:27, Maxime Ripard wrote: > On Mon, Apr 27, 2015 at 07:07:28PM +0100, Mark Brown wrote: >> On Mon, Apr 27, 2015 at 07:30:36PM +0200, Maxime Ripard wrote: >> > On Mon, Apr 27, 2015 at 11:16:01AM +0100, Mark Brown wrote: >> >> > > lkml.org is being terrible as usual so I can't see half the thread (or >> > > at least got fed up trying to get it to load) >> >> > A part of it is also here: >> > http://lkml.iu.edu/hypermail/linux/kernel/1405.0/00484.html >> >> OK, thanks. >> >> > > but I think the discussion there petered out more than anything >> > > else. >> >> > Maybe it did :) >> >> I think so looking at the archives. >> >> > > Or was it the suggestion to make this something that the driver core >> > > supported so that we didn't have to open code it for every bus? >> >> > Probably. That's something I really haven't took the time to look at, >> > and don't really plan on doing so. >> >> > I guess a good way forward would be to revive this patch, and wait for >> > that generic way to happen. >> >> > What do you think of this? >> >> Probably best, the Pi bootloader does make it a bit more important. >> Might also be worth speaking to Greg though. > > So, do you want me to resend that patch and discuss this directly > there (with Greg in Cc) ? My general idea is to get overlay loading to work and then make spidev bind to all CS which are not taken by anything and unbind when an overlay tries to take over the CS. Since there are some overlay loading patches available that part can be considered solved but I did not get to looking at the dynamic spidev binding. For now I use your patch with additional patch that marks the spidev devices with a flag so they are not checked when it is determined if the CS is in use. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/6] clk: sunxi: Add H3 clocks support
Hi,
On Sun, May 10, 2015 at 12:54:50PM +0200, Jens Kuske wrote:
> On 09/05/15 13:27, Maxime Ripard wrote:
> > On Wed, May 06, 2015 at 11:31:29AM +0200, Jens Kuske wrote:
> >> The H3 clock control unit is similar to the those of other sun8i family
> >> members like the A23.
> >>
> >> The AHB1 gates got split up into AHB1 and AHB2, with AHB2 clock source
> >> being muxable between AHB1 and PLL6/2, but still sharing gate registers.
> >> The documentation isn't totally clear about which devices belong to
> >> AHB2 now, especially USB EHIC/OHIC, so it is mostly based on Allwinner
> >> kernel source code.
> >>
> >> Signed-off-by: Jens Kuske
> >> ---
> >> Documentation/devicetree/bindings/clock/sunxi.txt | 7
> >> drivers/clk/sunxi/clk-sunxi.c | 46
> >> ++-
> >> 2 files changed, 52 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> >> b/Documentation/devicetree/bindings/clock/sunxi.txt
> >> index 4fa11af..4eeb893 100644
> >> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> >> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> >> @@ -14,6 +14,8 @@ Required properties:
> >>"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
> >>"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
> >>"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
> >> + "allwinner,sun8i-h3-pll6-clk" - for the PLL6 clock on H3
> >> + "allwinner,sun8i-h3-pll8-clk" - for the PLL8 clock on H3
> >>"allwinner,sun9i-a80-gt-clk" - for the GT bus clock on A80
> >>"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
> >>"allwinner,sun4i-a10-axi-clk" - for the AXI clock
> >> @@ -28,8 +30,11 @@ Required properties:
> >>"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
> >>"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
> >>"allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
> >> + "allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
> >>"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
> >>"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
> >> + "allwinner,sun8i-h3-ahb1-gates-clk" - for the AHB1 gates on H3
> >> + "allwinner,sun8i-h3-ahb2-gates-clk" - for the AHB2 gates on H3
> >>"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
> >>"allwinner,sun9i-a80-ahb1-gates-clk" - for the AHB1 gates on A80
> >>"allwinner,sun9i-a80-ahb2-gates-clk" - for the AHB2 gates on A80
> >> @@ -52,8 +57,10 @@ Required properties:
> >>"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
> >>"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
> >>"allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23
> >> + "allwinner,sun8i-h3-apb1-gates-clk" - for the APB1 gates on H3
> >>"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
> >>"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> >> + "allwinner,sun8i-h3-apb2-gates-clk" - for the APB2 gates on H3
> >>"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
> >>"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
> >>"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
> >> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> >> index 7e1e2bd..152a1f7 100644
> >> --- a/drivers/clk/sunxi/clk-sunxi.c
> >> +++ b/drivers/clk/sunxi/clk-sunxi.c
> >> @@ -727,6 +727,12 @@ static const struct factors_data sun5i_a13_ahb_data
> >> __initconst = {
> >>.getter = sun5i_a13_get_ahb_factors,
> >> };
> >>
> >> +static const struct factors_data sun8i_h3_pll8_data __initconst = {
> >> + .enable = 31,
> >> + .table = &sun6i_a31_pll6_config,
> >> + .getter = sun6i_a31_get_pll6_factors,
> >> +};
> >
> > This looks like it's just another instance of the A31 pll6.
> >
> > In such a case, we don't need to declare a new driver, just reuse the
> > same compatible.
>
> If I reuse pll6 for pll8 I get errors because of the .name = "pll6x2"
> field, already existing clock or something like that.
Damn. You're obviously right...
Could you add a TODO comment on top then? just so that we know that we
need to merge this clock with pll6?
> (And pll8 doesn't even have a x2 version)
Judging by the H3 datasheet, it does.
> >> static const struct factors_data sun4i_apb1_data __initconst = {
> >>.mux = 24,
> >>.muxmask = BIT(1) | BIT(0),
> >> @@ -777,6 +783,10 @@ static const struct mux_data sun6i_a31_ahb1_mux_data
> >> __initconst = {
> >>.shift = 12,
> >> };
> >>
> >> +static const struct mux_data sun8i_h3_ahb2_mux_data __initconst = {
> >> + .shift = 0,
> >> +};
> >> +
> >> static void __init sunxi_mux_clk_setup(struct device_node *node,
> >> struct mux_data *data)
> >> {
> >> @@ -892,7 +902,7 @@ static void __init sunxi_divider_clk_setup(struct
> >> device_node *node,
> >> * sunxi_gates_clk_setup
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 07:07:28PM +0100, Mark Brown wrote: > On Mon, Apr 27, 2015 at 07:30:36PM +0200, Maxime Ripard wrote: > > On Mon, Apr 27, 2015 at 11:16:01AM +0100, Mark Brown wrote: > > > > lkml.org is being terrible as usual so I can't see half the thread (or > > > at least got fed up trying to get it to load) > > > A part of it is also here: > > http://lkml.iu.edu/hypermail/linux/kernel/1405.0/00484.html > > OK, thanks. > > > > but I think the discussion there petered out more than anything > > > else. > > > Maybe it did :) > > I think so looking at the archives. > > > > Or was it the suggestion to make this something that the driver core > > > supported so that we didn't have to open code it for every bus? > > > Probably. That's something I really haven't took the time to look at, > > and don't really plan on doing so. > > > I guess a good way forward would be to revive this patch, and wait for > > that generic way to happen. > > > What do you think of this? > > Probably best, the Pi bootloader does make it a bit more important. > Might also be worth speaking to Greg though. So, do you want me to resend that patch and discuss this directly there (with Greg in Cc) ? 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
[linux-sunxi] Re: [PATCH 0/6] Introduce Allwinner A33 support
On Sun, May 10, 2015 at 8:46 AM, Vishnu Patekar wrote: > Hello everyone, > > This patch series introduces basic kernel support for Allwinner's A33 SoC, I'll wait for a new set addressing Paul's comments before commiting the pinctrl portions. Add Maxime's ACKs to the patches so I know he's verified them. Yours, Linus Walleij -- 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 R8 module
On Tue, May 12, 2015 at 3:01 AM, Marius Cirsta wrote: > >> Indeed , my guess is that info will be available soon on this R8 but I > guess these guys spilled the beans early. I also do wonder if it will still > have the Mali400. > > As for the board itself , let's see if they deliver and how they'll > cooperate with linux-sunxi. If it is indeed a sham than there will be a lot > of pissed people. > I think they had to give details about the SoC since they are doing the campaign on Kickstarter. It looks like their campaign will surpass $1m and there will be a lot of interest to get things done. Tsvetan mentioned in a prior blog post that Allwinner was OK to make a batch of at least 50K A10 SoCs, if requested ( https://olimex.wordpress.com/2015/04/07/how-50-000-a10-socs-from-allwinner-looks-like/). The C.H.I.P. campaign so far has pledges for about 23K R8 SoCs and it is bound to go much higher than that. Whether the R8 will be available outside the C.H.I.P. campaign, remains to be seen. With the RPi, it appears there was no exclusivity with Broadcom on paper but the RPi Foundation might have requested anyway from Broadcom not to sell the SoC to Hardkernel ( http://slated.org/the_curious_case_of_raspberry_pi_consumerism). It does not look like the campaigners for C.H.I.P. are the types to request exclusivity for the R8. For example, see their website at http://nextthing.co The "KERNEL HACKERS ONLY" pledge was already taken by 606 backers (est delivery: Sept 2015). Most probably these people will be joining this list to get mainline support for the device. Again, checking the campaigner's website at http://nextthing.co/ shows that they do not even have yet a forum or mailing list for their existing products. I think it is up to actions happening here, whether the whole thing will be beneficial to the linux-sunxi community. Personally, I am inclined to contact them. Simos -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 4/6] ARM: dts: sunxi: add common sun8i dtsi
Hi, On Tue, May 12, 2015 at 6:53 PM, wrote: > Thanks for your help. Is there a rom out there that doesn't say test keys. I > have found that the nowtv app looks at the rom type. I have just rooted it > using kingo root. I was hopeing to try using exposed and root cloak We don't do ROMs, you'll have to search for that yourself. It's highly unlikely that there will be though, Allwinner devices tend not to be popular enough to attract Android developers. As for test keys and root cloak and all that, I've never had to investigate any of those so I can't help you with that. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Banana R1 router german article
Small follow-up: I'm refering to GMAC send/receive clock delay chain. For Banana Pi/Pro it was necessary to set bit 10-12 of the gmac clk register to 3 to get decent network throughput (for Cubietruck it's set to 1 currently). http://lists.denx.de/pipermail/u-boot/2014-September/190239.html This is done in u-boot: http://lists.denx.de/pipermail/u-boot/2015-January/202590.html Since this is a very board specific value to compensate for trace lengths on the PCB (see explanation above) I had doubts that using also 3 on the Lamobo R1 (which has a totally different PCB and uses a different PHY than Banana Pi/Pro) would make any sense. Igor tried a few other values (2,4,5,6,7,9,12) and came up with 4 giving better results. So now he sets "CONFIG_GMAC_TX_DELAY=4" https://github.com/igorpecovnik/lib/blob/next/patch/add-lamobo-r1-uboot.patch If I have the time I will set up an unattended test setup and brute-force through all possible values of CONFIG_GMAC_TX_DELAY and also CONFIG_GMAC_RX_DELAY (why shouldn't the other direction not also be affected? This is what we have right now with all A20 boards: asymmetric throughput). With mainline kernel and adjusted SMP, network and cpufreq settings (also due to patched U-boot) I managed to get 940 Mbits/sec RX and 670 Mbits/sec TX: http://forum.lemaker.org/thread-12167-1-1-nas_performance_with_kernel_3_19_0.html This is what I want to achieve on the Lamobo R1 as well and try to reach 940 Mbits/sec TX on Banana Pi/Pro. But no idea whether the idea to set CONFIG_GMAC_RX_DELAY will work since code for this value in board/sunxi/gmac.c seems to be missing (and unfortunately I'm no coder) -- 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: Banana R1 router german article
Benjamin Henrion wrote: > http://www.pc-magazin.de/ratgeber/banana-pi-r1-router-anleitung-openwrt-bananian-3021511.html > > Anyone has ever tested this router? I heard they had problems to make > the BCM switch working properly. I have it here and Igor Pečovnik already added support for Mainline with recent u-boot in his Debian build system (he also adjusted GMAC send/receive clock adjustments in u-boot because right now the network throughput between SoC and BCM switch that acts as PHY is pretty slow): http://www.igorpecovnik.com/2014/09/07/banana-pi-debian-sd-image/ https://github.com/igorpecovnik/lib/tree/next/patch The BCM is also working with sunxi 3.4.x. When I still have the board next weekend (dedicated to a customer's project) I'll dig deeper into the network problem. Right now with Igor's u-boot adjustments we only get 350 Mbits/sec. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 4/6] ARM: dts: sunxi: add common sun8i dtsi
Thanks for your help. Is there a rom out there that doesn't say test keys. I have found that the nowtv app looks at the rom type. I have just rooted it using kingo root. I was hopeing to try using exposed and root cloak -- 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.
