[linux-sunxi] Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
On Sat, Jan 18, 2014 at 7:11 AM, Linus Walleij wrote: > On Fri, Jan 17, 2014 at 6:43 PM, Chen-Yu Tsai wrote: >> On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann wrote: > +- NAME_shutdown-gpios : GPIO phandle to shutdown control + (phandle must be the second) +- NAME_reset-gpios : GPIO phandle to reset control + +NAME must match the rfkill-name property. NAME_shutdown-gpios or +NAME_reset-gpios, or both, must be defined. + >>> >>> I don't understand this part. Why do you include the name in the >>> gpios property, rather than just hardcoding the property strings >>> to "shutdown-gpios" and "reset-gpios"? >> >> This quirk is a result of how gpiod_get_index implements device tree >> lookup. > > Why can't it just have a single property "gpios", where the first > element is the reset GPIO and the second is the shutdown GPIO? > > rfkill-gpio does this: > > gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0); > gpio = devm_gpiod_get_index(&pdev->dev, rfkill->shutdown_name, 1); > > The passed con ID name parameter is only there for the device > tree case it seems. (ACPI ignores it.) So what about you just > don't pass it at all and patch it to do like this instead: > > gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0); > gpio = devm_gpiod_get_index(&pdev->dev, NULL, 1); I'd like that. It's much cleaner. > Heikki, are you OK with this change? > > I think this is actually necessary if the ACPI and DT unification > pipe dream shall limp forward, we cannot have arguments passed > that have a semantic effect on DT but not on ACPI... Drivers > that are supposed to use both ACPI and DT will always > have to pass NULL as con ID. > >> If con_id is given, it is prepended to "gpios" as the property string. >> con_id is also used as the label passed to gpiod_request, which is >> then shown in /sys/kernel/debug/gpio. > > If your problem is really what turns up in debugfs, then we need > to figure out a way to label gpios outside of the *gpiod_get* calls. Let's add a gpiod_set_label call. Currently there's a desc_set_label in gpiolib, which is static inlined. We can either rename and promote it to non-static, or add a new wrapping function. > The string passed in *gpiod_get* is a "connection ID" not a proper > name for the GPIO. I see. Perhaps we should not pass this to gpiod_request as the label, or add a comment stating consumers can use the new gpiod_set_label call to change it. Cheers, 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/groups/opt_out.
[linux-sunxi] Re: How to test wifi in A20.
On Friday, January 17, 2014 2:54:45 AM UTC-5, Puneet B wrote:
>
> Hi,
>
> While tracing problem i found below issue.
>
> i am getting error in log as:
>
> [4.780261] [dhd_module_init] get wl_host_wake gpio failed
>
> The code is from here:./
>
> vim linux-sunxi/drivers/net/wireless/bcmdhd/dhd_linux.c +4396
>
> if (gpio_request(WL_HOST_WAKE_DEF_GPIO, "wl_host_wake")) {
> pr_warning("[%s] get wl_host_wake gpio failed\n",
> __FUNCTION__);
> wl_host_wake = -1;
> return -1;
> }
>
> Which means some gpio error:
>
> In script for wifi:
> ap6xxx_wl_regon = port:PH09<1><0>
> ap6xxx_wl_host_wake = port:PH10<0><0>
> ap6xxx_bt_regon = port:PB05<1><0>
> ap6xxx_bt_wake = port:PI20<1><0>
> ap6xxx_bt_host_wake = port:PI21<0><0>
> ap6xxx_lpo = port:PI12<4>
>
>
> For ap6xxx_wl_host_wake , i check by making high and low but error is
> same.
>
> Can any one tell why that error is, Is it because of some gpio pins or
> something else went wrong?
>
> Regards
> Punith
>
> The problem is that the stock bcmdhd driver doesn't know how to toggle the
allwinner gpios to turn on the chip. Cubietech made some changes for that
to drivers/net/wireless/bcmdhd/dhd_custom_gpio.c, which is meant by
Broadcom to be customized to different boards (thus the "custom" in the
name). It could all be abstracted pretty easily in the 3.4 linux-sunxi
kernel, except for a few new calls to sunximmc_rescan_card made after power
off and power on (probably not needed after the power off).
The mainline kernel abstracts this stuff much better than 3.4, so
backporting might not be so easy.
Pat
--
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/groups/opt_out.
Re: [linux-sunxi] [PATCH u-boot-sunxi] ARM: sunxi: get script.bin file name from env
Even in mainline, I see no reason to not to access the dtb file through an env variable (I haven't checked to see, perhaps it is). -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v3 0/8] ARM: sunxi: rename DT clock node names to clk@N
Quoting Emilio López (2014-01-16 19:06:15) > Hi, > > El 09/01/14 05:52, Chen-Yu Tsai escribió: > > This is v3 of the clock node renaming patch series, which renames > > the clock nodes in sunxi dts to conform to device tree naming > > conventions, i.e. clk@N. Dummy clocks that will be renamed/removed > > later, or clocks sharing registers are not renamed. > > > > Renamed clock nodes have clock-output-names properties added to > > desginate their names. Support for this is added in the first > > patch. > > > > Changes since v2: > > > >* Dropped Cubietruck dts i2c controller patch. Maxime has taken it. > >* Changed ARM in commit messages to uppercase. > >* Add pll5, pll6 clock names to factors_data tied to compatible strings. > >* Dropped pll5 output name in dts due to the previous change. > >* Added dts binding documentation for "clock-output-names", as well as > > examples. > > > > Changes since v1: > > > >* Fixed pll5, pll6 divs clock name handling > > > > Cheers > > ChenYu > > > > Chen-Yu Tsai (8): > >clk: sunxi: add clock-output-names dt property support > >clk: sunxi: update clock-output-names dt binding documentation > >clk: sunxi: add names for pll5, pll6 parent clocks to factors_data > >clk: sunxi: get divs parent clock name from parent factor clock > >ARM: dts: sun4i: rename clock node names to clk@N > >ARM: dts: sun5i: rename clock node names to clk@N > >ARM: dts: sun6i: rename clock node names to clk@N > >ARM: dts: sun7i: rename clock node names to clk@N > > > > Documentation/devicetree/bindings/clock/sunxi.txt | 36 > > +++ > > arch/arm/boot/dts/sun4i-a10.dtsi | 24 --- > > arch/arm/boot/dts/sun5i-a10s.dtsi | 24 --- > > arch/arm/boot/dts/sun5i-a13.dtsi | 24 --- > > arch/arm/boot/dts/sun6i-a31.dtsi | 12 > > arch/arm/boot/dts/sun7i-a20.dtsi | 19 +++- > > drivers/clk/sunxi/clk-sunxi.c | 36 > > --- > > 7 files changed, 117 insertions(+), 58 deletions(-) > > The series looks good to me, other than the comment I made. Once that's > settled, and if Mike, Maxime or anyone else have no further comments, > I'll queue 1-4 for 3.15. Ack for patches 1-4. Regards, Mike > > Cheers, and thanks for working on this! > > Emilio -- 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/groups/opt_out.
Re: [linux-sunxi] Re: [PATCH] Add Full Duplex support to SPI (v2)
fre 2014-01-17 klockan 04:23 -0800 skrev montesi...@gmail.com: > On Wednesday, 8 January 2014 13:46:16 UTC+1, 郑志煜 wrote: > > I contacted the FAE engineer of Allwinner in monday, he said they had not > > verified the SPI driver code. So they don't know if the SPI FDX mode > > works.. It's very easy to test SPI full duplex even without any SPI devices. Just loopback MISO and MOSI and use spi-test to send a sufficiently large message. https://github.com/ORSoC/spi-test If you get the exact same message back with no shifting in any direction then full duplex works, and nothing if MISO and MISO is not connected in loopback to each other. Regards Henrik -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
On Fri, Jan 17, 2014 at 6:43 PM, Chen-Yu Tsai wrote: > On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann wrote: >>> +- NAME_shutdown-gpios : GPIO phandle to shutdown control >>> + (phandle must be the second) >>> +- NAME_reset-gpios : GPIO phandle to reset control >>> + >>> +NAME must match the rfkill-name property. NAME_shutdown-gpios or >>> +NAME_reset-gpios, or both, must be defined. >>> + >> >> I don't understand this part. Why do you include the name in the >> gpios property, rather than just hardcoding the property strings >> to "shutdown-gpios" and "reset-gpios"? > > This quirk is a result of how gpiod_get_index implements device tree > lookup. Why can't it just have a single property "gpios", where the first element is the reset GPIO and the second is the shutdown GPIO? rfkill-gpio does this: gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0); gpio = devm_gpiod_get_index(&pdev->dev, rfkill->shutdown_name, 1); The passed con ID name parameter is only there for the device tree case it seems. (ACPI ignores it.) So what about you just don't pass it at all and patch it to do like this instead: gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0); gpio = devm_gpiod_get_index(&pdev->dev, NULL, 1); Heikki, are you OK with this change? I think this is actually necessary if the ACPI and DT unification pipe dream shall limp forward, we cannot have arguments passed that have a semantic effect on DT but not on ACPI... Drivers that are supposed to use both ACPI and DT will always have to pass NULL as con ID. > If con_id is given, it is prepended to "gpios" as the property string. > con_id is also used as the label passed to gpiod_request, which is > then shown in /sys/kernel/debug/gpio. If your problem is really what turns up in debugfs, then we need to figure out a way to label gpios outside of the *gpiod_get* calls. The string passed in *gpiod_get* is a "connection ID" not a proper name for the GPIO. 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/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] clk: sunxi: Add support for PLL6 on the A31
Quoting Maxime Ripard (2014-01-16 09:11:22)
> The A31 has a slightly different PLL6 clock. Add support for this new clock in
> our driver.
>
> Signed-off-by: Maxime Ripard
This looks good to me. I guess it will be going in for 3.15 based on the
comments in the coverletter.
Regards,
Mike
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> drivers/clk/sunxi/clk-sunxi.c | 45
> +++
> 2 files changed, 46 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index c2cb762..954845c 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -11,6 +11,7 @@ Required properties:
> "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
> "allwinner,sun4i-pll5-clk" - for the PLL5 clock
> "allwinner,sun4i-pll6-clk" - for the PLL6 clock
> + "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
> "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
> "allwinner,sun4i-axi-clk" - for the AXI clock
> "allwinner,sun4i-axi-gates-clk" - for the AXI gates
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 659e4ea..990ad5d 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -249,7 +249,38 @@ static void sun4i_get_pll5_factors(u32 *freq, u32
> parent_rate,
> *n = DIV_ROUND_UP(div, (*k+1));
> }
>
> +/**
> + * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
> + * PLL6 rate is calculated as follows
> + * rate = parent_rate * n * (k + 1) / 2
> + * parent_rate is always 24Mhz
> + */
> +
> +static void sun6i_a31_get_pll6_factors(u32 *freq, u32 parent_rate,
> + u8 *n, u8 *k, u8 *m, u8 *p)
> +{
> + u8 div;
> +
> + /*
> +* We always have 24MHz / 2, so we can just say that our
> +* parent clock is 12MHz.
> +*/
> + parent_rate = parent_rate / 2;
> +
> + /* Normalize value to a parent_rate multiple (24M / 2) */
> + div = *freq / parent_rate;
> + *freq = parent_rate * div;
> +
> + /* we were called to round the frequency, we can now return */
> + if (n == NULL)
> + return;
> +
> + *k = div / 32;
> + if (*k > 3)
> + *k = 3;
>
> + *n = DIV_ROUND_UP(div, (*k+1));
> +}
>
> /**
> * sun4i_get_apb1_factors() - calculates m, p factors for APB1
> @@ -416,6 +447,13 @@ static struct clk_factors_config sun4i_pll5_config = {
> .kwidth = 2,
> };
>
> +static struct clk_factors_config sun6i_a31_pll6_config = {
> + .nshift = 8,
> + .nwidth = 5,
> + .kshift = 4,
> + .kwidth = 2,
> +};
> +
> static struct clk_factors_config sun4i_apb1_config = {
> .mshift = 0,
> .mwidth = 5,
> @@ -457,6 +495,12 @@ static const struct factors_data sun4i_pll5_data
> __initconst = {
> .getter = sun4i_get_pll5_factors,
> };
>
> +static const struct factors_data sun6i_a31_pll6_data __initconst = {
> + .enable = 31,
> + .table = &sun6i_a31_pll6_config,
> + .getter = sun6i_a31_get_pll6_factors,
> +};
> +
> static const struct factors_data sun4i_apb1_data __initconst = {
> .table = &sun4i_apb1_config,
> .getter = sun4i_get_apb1_factors,
> @@ -972,6 +1016,7 @@ free_clkdata:
> static const struct of_device_id clk_factors_match[] __initconst = {
> {.compatible = "allwinner,sun4i-pll1-clk", .data = &sun4i_pll1_data,},
> {.compatible = "allwinner,sun6i-a31-pll1-clk", .data =
> &sun6i_a31_pll1_data,},
> + {.compatible = "allwinner,sun6i-a31-pll6-clk", .data =
> &sun6i_a31_pll6_data,},
> {.compatible = "allwinner,sun4i-apb1-clk", .data = &sun4i_apb1_data,},
> {.compatible = "allwinner,sun4i-mod0-clk", .data = &sun4i_mod0_data,},
> {.compatible = "allwinner,sun7i-a20-out-clk", .data =
> &sun7i_a20_out_data,},
> --
> 1.8.4.2
>
--
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/groups/opt_out.
[linux-sunxi] Re: [PATCH RFC 0/6] net: rfkill: gpio: Add device tree support
On Fri, 2014-01-17 at 14:47 +0800, Chen-Yu Tsai wrote: > This patch series adds device tree support to rfkill-gpio, and > fixes some issues I ran into. This is so we can define and control > RF devices through the device tree, such as the Broadcom BCM20710 > UART-based Bluetooth device found on the CubieTruck, > Comments, please? Does anyone else want to maintain rfkill-gpio? :) I'm not up to par on all the DT, ACPI and even GPIO stuff it does, and the rfkill bits in it are really small ... I'll happily apply the patches if everyone else is happy with them, but please don't expect me to actually be able to say anything about them. johannes -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
On Friday 17 January 2014, Chen-Yu Tsai wrote: > On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann wrote: > > On Friday 17 January 2014, Chen-Yu Tsai wrote: > >> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt > >> b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt > >> new file mode 100644 > >> index 000..8a07ea4 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt > >> @@ -0,0 +1,26 @@ > >> +GPIO controlled RFKILL devices > >> + > >> +Required properties: > >> +- compatible : Must be "rfkill-gpio". > >> +- rfkill-name : Name of RFKILL device > >> +- rfkill-type : Type of RFKILL device: 1 for WiFi, 2 for BlueTooth > >> +- NAME_shutdown-gpios : GPIO phandle to shutdown control > >> + (phandle must be the second) > >> +- NAME_reset-gpios : GPIO phandle to reset control > >> + > >> +NAME must match the rfkill-name property. NAME_shutdown-gpios or > >> +NAME_reset-gpios, or both, must be defined. > >> + > > > > I don't understand this part. Why do you include the name in the > > gpios property, rather than just hardcoding the property strings > > to "shutdown-gpios" and "reset-gpios"? > > This quirk is a result of how gpiod_get_index implements device tree > lookup. You'll also notice that the shutdown GPIO must be the second > phandle, as the driver uses indexed lookup to support ACPI cases. > If con_id is given, it is prepended to "gpios" as the property string. > con_id is also used as the label passed to gpiod_request, which is > then shown in /sys/kernel/debug/gpio. The Linux implementation should not enforce an inferior DT binding. I think it would be better to change the code instead and make this work with a more sensible representation. > I can do a seperate lookup for the device tree case, with or without > fallback to platform lookup tables. Then the names can be "reset-gpio" > and "shutdown-gpio". Need to promote gpiod_request to non-static so > we can register usage of the gpio, to match non-dt code path. > > Personally I prefer adding a "label" parameter to gpiod_get_index, so > we can use a different name than con_id. con_id isn't used in the ACPI > case, and is optional in platform lookup case. However device tree > lookup is dependent on this. What I see is non-uniform behavior > between the three. In my opinion this is undesirable, but I haven't > come up with a good solution yet. (adding the gpio people here). I don't understand enough of the current API to make a good call here, but I agree that we should try to make it more uniform and do it in a way that allows simpler DT bindings for devices using it. > About the property string, is the plural form required, even though we > only want one? I would keep the plural form for consistency. Arnd -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Uart 6+7
Im Trying to use Uart 6 + 7 on PI Port and im not sure is my script.bin settings are correct Can someone please verify: [uart_para6] uart_used = 1 uart_port = 6 uart_type = 2 uart_tx = port:PI12<3><1> uart_rx = port:PI13<3><1> [uart_para7] uart_used = 1 uart_port = 7 uart_type = 2 uart_tx = port:PI20<4><1> uart_rx = port:PI21<4><1> Regards -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH 3/4] spi: sunxi: Add Allwinner A31 SPI controller driver
On Thu, Jan 16, 2014 at 10:12:01PM +0100, Maxime Ripard wrote:
> On Thu, Jan 16, 2014 at 07:40:03PM +, Mark Brown wrote:
> > > + if (status & SUN6I_INT_CTL_RF_OVF) {
> > > + sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
> > > + sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_RF_OVF);
> > > + return IRQ_HANDLED;
> > > + }
> > This looks like an overflow - a log message would be helpful for users
> > and you should possibly be flagging an error on the current transfer.
> Hmmm, that was an attempt at receiving more bytes than the FIFO can
> handle, but I guess the FIFO full interrupt would be more appropriate
> for this.
If you've got an overflow interrupt that suggests that the data is
already corrupted, assuming the interrupt isn't misnamed.
> > > + ret = clk_set_rate(sspi->mclk, 1);
> > > + if (ret) {
> > > + dev_err(&pdev->dev, "Couldn't change module clock rate\n");
> > > + goto err2;
> > > + }
> > Does this really need to be fatal (or done at all)? There seems to be
> > another reasonably flexible divider in the IP and it's more common to
> > either set this per transfer to something that rounds nicely or just use
> > the default and rely on the dividers.
> The default parent of the module clock runs at 24MHz, that means that
> we won't be able to reach a spi clock higher than 12MHz, which seems
> quite low. We can always change the rate in the transfer setup code
> though, if needs be.
12MHz is actually quite a common limit for SPI interfaces (half of a
24MHz master clock like the IP itself has) but yeah, you want to go
higher if you can. Doing it on transfer setup is going to mean that
you save a little power when you don't need the extra speed too.
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann wrote: > On Friday 17 January 2014, Chen-Yu Tsai wrote: >> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> new file mode 100644 >> index 000..8a07ea4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> @@ -0,0 +1,26 @@ >> +GPIO controlled RFKILL devices >> + >> +Required properties: >> +- compatible : Must be "rfkill-gpio". >> +- rfkill-name : Name of RFKILL device >> +- rfkill-type : Type of RFKILL device: 1 for WiFi, 2 for BlueTooth >> +- NAME_shutdown-gpios : GPIO phandle to shutdown control >> + (phandle must be the second) >> +- NAME_reset-gpios : GPIO phandle to reset control >> + >> +NAME must match the rfkill-name property. NAME_shutdown-gpios or >> +NAME_reset-gpios, or both, must be defined. >> + > > I don't understand this part. Why do you include the name in the > gpios property, rather than just hardcoding the property strings > to "shutdown-gpios" and "reset-gpios"? This quirk is a result of how gpiod_get_index implements device tree lookup. You'll also notice that the shutdown GPIO must be the second phandle, as the driver uses indexed lookup to support ACPI cases. If con_id is given, it is prepended to "gpios" as the property string. con_id is also used as the label passed to gpiod_request, which is then shown in /sys/kernel/debug/gpio. I can do a seperate lookup for the device tree case, with or without fallback to platform lookup tables. Then the names can be "reset-gpio" and "shutdown-gpio". Need to promote gpiod_request to non-static so we can register usage of the gpio, to match non-dt code path. Personally I prefer adding a "label" parameter to gpiod_get_index, so we can use a different name than con_id. con_id isn't used in the ACPI case, and is optional in platform lookup case. However device tree lookup is dependent on this. What I see is non-uniform behavior between the three. In my opinion this is undesirable, but I haven't come up with a good solution yet. About the property string, is the plural form required, even though we only want one? Thanks! ChenYu > The description of hte "rfkill-name" property seems to suggest > that you can only have one logical RFKILL device per device node, > so he names would not be ambiguous. > > Arnd -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] 24-bit Audio Isn't Working
We're getting closer. I was able to meet briefly with Allwinner at CES and they are helping us now. We are very close now I think and with some luck we may solve this over the weekend. On Fri, Jan 17, 2014 at 4:41 AM, Olliver Schinagl wrote: > I don't think anybody here has tested this yet either. So any findings are > very welcome! > > Oliver > > > On 13-01-14 05:29, George Ioakimedes wrote: > >> We've been looking into supporting high resolution audio file playback, >> specifically 24-bit/96kHz and 24-bit/192kHz files. We've made some >> changes and had a little progress but are still not able to get proper >> playback of 24-bit audio files. I'm hoping that by posting here someone >> else has looked at this or has some ideas of what is needed to get this >> working. We've confirmed with Allwinner that it should work but that it >> was never tested. >> >> -- >> 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/groups/opt_out. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "linux-sunxi" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/linux-sunxi/BylDdcI-2HA/unsubscribe. > To unsubscribe from this group and all of its topics, send an email to > linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v7 0/2] ohci and ehci-platform clks, phy and dt support
On Thu, 16 Jan 2014, Florian Fainelli wrote: > Le mercredi 15 janvier 2014, 15:26:21 Alan Stern a écrit : > > On Wed, 15 Jan 2014, Hans de Goede wrote: > > > Hi All, > > > > > > This version of my ohci and ehci-platform clks, phy and dt support > > > patch-set, really fixes the 2 small bugs Alan found. > > > > All okay -- this time I can't find anything to complain about. :-) > > There is one minor issue; which is that the ehci binding claims the driver > supports the following optional boolean properties: > > - big-endian-regs : boolean, set this for hcds with big-endian registers > - big-endian-desc : boolean, set this for hcds with big-endian descriptors > - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc > > while it does not (yet) so this is misleading. Can we at get that fixed > before > merging? Copy pasting the PPC ehci driver should do the job. I agree it needs to be fixed. This can be done in a follow-up patch, though. It doesn't have to be in this one because nobody is using ehci-platform with DT yet. A simple copy from the PPC driver isn't quite enough, because the platform data settings would override the DT values. ehci_platform_reset has to be changed so that it sets ehci->big_endian_desc and _mmio if the pdata flags are set, but otherwise leaves them alone. Hans, would you like to write another patch to take care of this? Alan Stern -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
On Friday 17 January 2014, Chen-Yu Tsai wrote: > diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt > b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt > new file mode 100644 > index 000..8a07ea4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt > @@ -0,0 +1,26 @@ > +GPIO controlled RFKILL devices > + > +Required properties: > +- compatible : Must be "rfkill-gpio". > +- rfkill-name : Name of RFKILL device > +- rfkill-type : Type of RFKILL device: 1 for WiFi, 2 for BlueTooth > +- NAME_shutdown-gpios : GPIO phandle to shutdown control > + (phandle must be the second) > +- NAME_reset-gpios : GPIO phandle to reset control > + > +NAME must match the rfkill-name property. NAME_shutdown-gpios or > +NAME_reset-gpios, or both, must be defined. > + I don't understand this part. Why do you include the name in the gpios property, rather than just hardcoding the property strings to "shutdown-gpios" and "reset-gpios"? The description of hte "rfkill-name" property seems to suggest that you can only have one logical RFKILL device per device node, so he names would not be ambiguous. Arnd -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH net-next v3 7/8] net: stmmac: Use driver data and callbacks tied with compatible strings
The stmmac driver core allows passing feature flags and callbacks via
platform data. Add a similar stmmac_of_data to pass flags and callbacks
tied to compatible strings. This allows us to extend stmmac with glue
layers for different SoCs.
Signed-off-by: Chen-Yu Tsai
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 44 +-
include/linux/stmmac.h | 18 +
2 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 82110f1..bf119db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -26,8 +26,20 @@
#include
#include
#include
+#include
#include "stmmac.h"
+static const struct of_device_id stmmac_dt_ids[] = {
+ /* SoC specific glue layers should come before generic bindings */
+ { .compatible = "st,spear600-gmac"},
+ { .compatible = "snps,dwmac-3.610"},
+ { .compatible = "snps,dwmac-3.70a"},
+ { .compatible = "snps,dwmac-3.710"},
+ { .compatible = "snps,dwmac"},
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, stmmac_dt_ids);
+
#ifdef CONFIG_OF
static int stmmac_probe_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *plat,
@@ -35,10 +47,32 @@ static int stmmac_probe_config_dt(struct platform_device
*pdev,
{
struct device_node *np = pdev->dev.of_node;
struct stmmac_dma_cfg *dma_cfg;
+ const struct of_device_id *device;
if (!np)
return -ENODEV;
+ device = of_match_device(stmmac_dt_ids, &pdev->dev);
+ if (!device)
+ return -ENODEV;
+
+ if (device->data) {
+ const struct stmmac_of_data *data = device->data;
+ plat->has_gmac = data->has_gmac;
+ plat->enh_desc = data->enh_desc;
+ plat->tx_coe = data->tx_coe;
+ plat->rx_coe = data->rx_coe;
+ plat->bugged_jumbo = data->bugged_jumbo;
+ plat->pmt = data->pmt;
+ plat->riwt_off = data->riwt_off;
+ plat->fix_mac_speed = data->fix_mac_speed;
+ plat->bus_setup = data->bus_setup;
+ plat->setup = data->setup;
+ plat->free = data->free;
+ plat->init = data->init;
+ plat->exit = data->exit;
+ }
+
*mac = of_get_mac_address(np);
plat->interface = of_get_phy_mode(np);
@@ -259,16 +293,6 @@ static int stmmac_pltfr_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(stmmac_pltfr_pm_ops,
stmmac_pltfr_suspend, stmmac_pltfr_resume);
-static const struct of_device_id stmmac_dt_ids[] = {
- { .compatible = "st,spear600-gmac"},
- { .compatible = "snps,dwmac-3.610"},
- { .compatible = "snps,dwmac-3.70a"},
- { .compatible = "snps,dwmac-3.710"},
- { .compatible = "snps,dwmac"},
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, stmmac_dt_ids);
-
struct platform_driver stmmac_pltfr_driver = {
.probe = stmmac_pltfr_probe,
.remove = stmmac_pltfr_remove,
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 0a5a7ac..1367974 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -121,4 +121,22 @@ struct plat_stmmacenet_data {
void *custom_data;
void *bsp_priv;
};
+
+/* of_data for SoC glue layer device tree bindings */
+
+struct stmmac_of_data {
+ int has_gmac;
+ int enh_desc;
+ int tx_coe;
+ int rx_coe;
+ int bugged_jumbo;
+ int pmt;
+ int riwt_off;
+ void (*fix_mac_speed)(void *priv, unsigned int speed);
+ void (*bus_setup)(void __iomem *ioaddr);
+ void *(*setup)(struct platform_device *pdev);
+ void (*free)(struct platform_device *pdev, void *priv);
+ int (*init)(struct platform_device *pdev, void *priv);
+ void (*exit)(struct platform_device *pdev, void *priv);
+};
#endif
--
1.8.5.2
--
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/groups/opt_out.
[linux-sunxi] [PATCH net-next v3 2/8] net: stmmac: Add support for optional reset control
The DWMAC has a reset assert line, which is used on some SoCs. Add an
optional reset control to stmmac driver core.
To support reset control deferred probing, this patch changes the driver
probe function to return the actual error, instead of just -EINVAL.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/net/stmmac.txt | 3 +++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ++--
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 ++--
6 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index eba0e5e..d132513 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -30,6 +30,9 @@ Required properties:
Optional properties:
- mac-address: 6 bytes, mac address
+- resets: Should contain a phandle to the STMMAC reset signal, if any
+- reset-names: Should contain the reset signal name "stmmaceth", if a
+ reset phandle is given
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 6e52c0f..b59d1ef 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -5,6 +5,7 @@ config STMMAC_ETH
select PHYLIB
select CRC32
select PTP_1588_CLOCK
+ select RESET_CONTROLLER
---help---
This is the driver for the Ethernet IPs are built around a
Synopsys IP Core and only tested on the STMicroelectronics
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 73709e9..c1c141f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -32,6 +32,7 @@
#include
#include "common.h"
#include
+#include
struct stmmac_priv {
/* Frequently used values are kept adjacent for cache effect */
@@ -91,6 +92,7 @@ struct stmmac_priv {
int wolopts;
int wol_irq;
struct clk *stmmac_clk;
+ struct reset_control *stmmac_rst;
int clk_csr;
struct timer_list eee_ctrl_timer;
int lpi_irq;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0d2c4cb..0c5c120 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -51,6 +51,7 @@
#include
#include "stmmac_ptp.h"
#include "stmmac.h"
+#include
#define STMMAC_ALIGN(x)L1_CACHE_ALIGN(x)
#define JUMBO_LEN 9000
@@ -2728,10 +2729,24 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
if (IS_ERR(priv->stmmac_clk)) {
dev_warn(priv->device, "%s: warning: cannot get CSR clock\n",
__func__);
+ ret = PTR_ERR(priv->stmmac_clk);
goto error_clk_get;
}
clk_prepare_enable(priv->stmmac_clk);
+ priv->stmmac_rst = devm_reset_control_get(priv->device,
+ STMMAC_RESOURCE_NAME);
+ if (IS_ERR(priv->stmmac_rst)) {
+ if (PTR_ERR(priv->stmmac_rst) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto error_hw_init;
+ }
+ dev_info(priv->device, "no reset control found\n");
+ priv->stmmac_rst = NULL;
+ }
+ if (priv->stmmac_rst)
+ reset_control_deassert(priv->stmmac_rst);
+
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
if (ret)
@@ -2808,7 +2823,7 @@ error_hw_init:
error_clk_get:
free_netdev(ndev);
- return NULL;
+ return ERR_PTR(ret);
}
/**
@@ -2832,6 +2847,8 @@ int stmmac_dvr_remove(struct net_device *ndev)
stmmac_mdio_unregister(ndev);
netif_carrier_off(ndev);
unregister_netdev(ndev);
+ if (priv->stmmac_rst)
+ reset_control_assert(priv->stmmac_rst);
clk_disable_unprepare(priv->stmmac_clk);
free_netdev(ndev);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 37ba2e0..2916089 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -100,9 +100,9 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
stmmac_default_data();
priv = stmmac_dvr_probe(&(pdev->dev), &plat_dat, addr);
- if (!priv) {
+ if (IS_ERR(priv)) {
pr_err("%s: main driver probe failed", __func__);
- ret = -ENODEV;
+ re
[linux-sunxi] [PATCH net-next v3 0/8] net: stmmac: Add Allwinner A20 GMAC ethernet
Hi, This is v3 of the Allwinner A20 GMAC glue layer for stmmac. I have split the series into stmmac driver changes for net-next, and clock and DT patches for their respective trees. The Allwinner A20 SoC integrates an early version of dwmac IP from Synopsys. On top of that is a hardware glue layer. This layer needs to be configured before the dwmac can be used. Part of the glue layer is a clock mux, which controls the source and direction of the TX clock used by GMAC. The glue layer is implemented with existing feature flags and callbacks found in stmmac driver core. A new stmmac_of_data structure, which is a subset of the original platform data, has been added to tie these values with compatible strings. The purpose of this is to avoid future glue layers assuming they can pass other data or directly modify values used by the driver core. This is found in patch #7. The callbacks have also been extended to pass board specific data. This is found in patch #3. This version of dwmac IP requires store and forward DMA mode. The relevant device tree property was documented, but not implemented. Patch #6 adds this to stmmac platform driver. Changes since v2: * Dropped non CONFIG_RESET_CONTROLLER routines, make stmmac select CONFIG_RESET_CONTROLLER * Split out "Deprecate snps,phy-addr and auto-detect PHY address" from "Use driver data and callbacks tied with compatible strings" * Added comments on how sunxi glue layer uses GMAC clock * Rebased onto net-next * Corrected typo in blackfin commit message Changes since v1: * Added optional reset control to stmmac driver core * Added non CONFIG_RESET_CONROLLER routines for the above change * Extended callback API, as discussed with Srinivas * Used new stmmac_of_data to pass features and callbacks, instead of platform data, as discussed * Seperated clock module glue layer into clock driver Cheers, ChenYu Chen-Yu Tsai (8): net: stmmac: Enable stmmac main clock when probing hardware net: stmmac: Add support for optional reset control net: stmmac: Allocate and pass soc/board specific data to callbacks blackfin: Update stmmac callback signatures net: stmmac: Honor DT parameter to force DMA store and forward mode net: stmmac: Deprecate snps,phy-addr and auto-detect PHY address net: stmmac: Use driver data and callbacks tied with compatible strings net: stmmac: sunxi platform extensions for GMAC in Allwinner A20 SoC's .../bindings/net/allwinner,sun7i-a20-gmac.txt | 27 Documentation/devicetree/bindings/net/stmmac.txt | 4 +- Documentation/networking/stmmac.txt| 12 +- arch/blackfin/mach-bf609/boards/ezkit.c| 2 +- drivers/net/ethernet/stmicro/stmmac/Kconfig| 12 ++ drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 141 + drivers/net/ethernet/stmicro/stmmac/stmmac.h | 5 + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 45 +-- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 80 +--- include/linux/stmmac.h | 24 +++- 12 files changed, 316 insertions(+), 41 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c -- 1.8.5.2 -- 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/groups/opt_out.
[linux-sunxi] [PATCH net-next v3 4/8] blackfin: Update stmmac callback signatures
stmmac callbacks have been extended for better separation.
Update them to avoid breakage.
Signed-off-by: Chen-Yu Tsai
---
arch/blackfin/mach-bf609/boards/ezkit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/blackfin/mach-bf609/boards/ezkit.c
b/arch/blackfin/mach-bf609/boards/ezkit.c
index 82beedd..05194e9 100644
--- a/arch/blackfin/mach-bf609/boards/ezkit.c
+++ b/arch/blackfin/mach-bf609/boards/ezkit.c
@@ -117,7 +117,7 @@ static struct stmmac_dma_cfg eth_dma_cfg = {
.pbl= 2,
};
-int stmmac_ptp_clk_init(struct platform_device *pdev)
+int stmmac_ptp_clk_init(struct platform_device *pdev, void *priv)
{
bfin_write32(PADS0_EMAC_PTP_CLKSEL, 0);
return 0;
--
1.8.5.2
--
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/groups/opt_out.
[linux-sunxi] [PATCH net-next v3 5/8] net: stmmac: Honor DT parameter to force DMA store and forward mode
"snps,force_sf_dma_mode" is documented in stmmac device tree bindings, but is never handled by the driver. Signed-off-by: Chen-Yu Tsai --- drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index 704a5e0..634260e 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -56,6 +56,8 @@ static int stmmac_probe_config_dt(struct platform_device *pdev, sizeof(struct stmmac_mdio_bus_data), GFP_KERNEL); + plat->force_sf_dma_mode = of_property_read_bool(np, "snps,force_sf_dma_mode"); + /* * Currently only the properties needed on SPEAr600 * are provided. All other properties should be added -- 1.8.5.2 -- 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/groups/opt_out.
[linux-sunxi] [PATCH net-next v3 3/8] net: stmmac: Allocate and pass soc/board specific data to callbacks
The current .init and .exit callbacks requires access to driver
private data structures. This is not a good seperation and abstraction.
Instead, we add a new .setup callback for allocating private data, and
pass the returned pointer to the other callbacks.
Signed-off-by: Chen-Yu Tsai
---
Documentation/networking/stmmac.txt | 12
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 18 ++
include/linux/stmmac.h| 6 --
3 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/Documentation/networking/stmmac.txt
b/Documentation/networking/stmmac.txt
index cdd916d..2090895 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -127,8 +127,9 @@ struct plat_stmmacenet_data {
int riwt_off;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void (*bus_setup)(void __iomem *ioaddr);
- int (*init)(struct platform_device *pdev);
- void (*exit)(struct platform_device *pdev);
+ void *(*setup)(struct platform_device *pdev);
+ int (*init)(struct platform_device *pdev, void *priv);
+ void (*exit)(struct platform_device *pdev, void *priv);
void *custom_cfg;
void *custom_data;
void *bsp_priv;
@@ -169,10 +170,13 @@ Where:
o bus_setup: perform HW setup of the bus. For example, on some ST platforms
this field is used to configure the AMBA bridge to generate more
efficient STBus traffic.
- o init/exit: callbacks used for calling a custom initialization;
+ o setup/init/exit: callbacks used for calling a custom initialization;
this is sometime necessary on some platforms (e.g. ST boxes)
where the HW needs to have set some PIO lines or system cfg
-registers.
+registers. setup should return a pointer to private data,
+which will be stored in bsp_priv, and then passed to init and
+exit callbacks. init/exit callbacks should not use or modify
+platform data.
o custom_cfg/custom_data: this is a custom configuration that can be passed
while initializing the resources.
o bsp_priv: another private pointer.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index cc6b89a7..704a5e0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -144,9 +144,16 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
}
}
+ /* Custom setup (if needed) */
+ if (plat_dat->setup) {
+ plat_dat->bsp_priv = plat_dat->setup(pdev);
+ if (IS_ERR(plat_dat->bsp_priv))
+ return PTR_ERR(plat_dat->bsp_priv);
+ }
+
/* Custom initialisation (if needed)*/
if (plat_dat->init) {
- ret = plat_dat->init(pdev);
+ ret = plat_dat->init(pdev, plat_dat->bsp_priv);
if (unlikely(ret))
return ret;
}
@@ -203,7 +210,10 @@ static int stmmac_pltfr_remove(struct platform_device
*pdev)
int ret = stmmac_dvr_remove(ndev);
if (priv->plat->exit)
- priv->plat->exit(pdev);
+ priv->plat->exit(pdev, priv->plat->bsp_priv);
+
+ if (priv->plat->free)
+ priv->plat->free(pdev, priv->plat->bsp_priv);
return ret;
}
@@ -218,7 +228,7 @@ static int stmmac_pltfr_suspend(struct device *dev)
ret = stmmac_suspend(ndev);
if (priv->plat->exit)
- priv->plat->exit(pdev);
+ priv->plat->exit(pdev, priv->plat->bsp_priv);
return ret;
}
@@ -230,7 +240,7 @@ static int stmmac_pltfr_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
if (priv->plat->init)
- priv->plat->init(pdev);
+ priv->plat->init(pdev, priv->plat->bsp_priv);
return stmmac_resume(ndev);
}
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 33ace71..0a5a7ac 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -113,8 +113,10 @@ struct plat_stmmacenet_data {
int max_speed;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void (*bus_setup)(void __iomem *ioaddr);
- int (*init)(struct platform_device *pdev);
- void (*exit)(struct platform_device *pdev);
+ void *(*setup)(struct platform_device *pdev);
+ void (*free)(struct platform_device *pdev, void *priv);
+ int (*init)(struct platform_device *pdev, void *priv);
+ void (*exit)(struct platform_device *pdev, void *priv);
void *custom_cfg;
void *custom_data;
void *bsp_priv;
--
1.8.5.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" gro
[linux-sunxi] [PATCH net-next v3 1/8] net: stmmac: Enable stmmac main clock when probing hardware
The stmmac driver does not enable the main clock during the probe phase.
If the clock was not enabled by the boot loader or was disabled by the
kernel, hardware features and the MDIO bus would not be probed properly.
Signed-off-by: Chen-Yu Tsai
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 26 +++
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index cddcf76..0d2c4cb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1680,8 +1680,6 @@ static int stmmac_open(struct net_device *dev)
struct stmmac_priv *priv = netdev_priv(dev);
int ret;
- clk_prepare_enable(priv->stmmac_clk);
-
stmmac_check_ether_addr(priv);
if (priv->pcs != STMMAC_PCS_RGMII && priv->pcs != STMMAC_PCS_TBI &&
@@ -1819,7 +1817,6 @@ static int stmmac_release(struct net_device *dev)
#ifdef CONFIG_STMMAC_DEBUG_FS
stmmac_exit_fs();
#endif
- clk_disable_unprepare(priv->stmmac_clk);
stmmac_release_ptp(priv);
@@ -2727,10 +2724,18 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
if ((phyaddr >= 0) && (phyaddr <= 31))
priv->plat->phy_addr = phyaddr;
+ priv->stmmac_clk = devm_clk_get(priv->device, STMMAC_RESOURCE_NAME);
+ if (IS_ERR(priv->stmmac_clk)) {
+ dev_warn(priv->device, "%s: warning: cannot get CSR clock\n",
+__func__);
+ goto error_clk_get;
+ }
+ clk_prepare_enable(priv->stmmac_clk);
+
/* Init MAC and get the capabilities */
ret = stmmac_hw_init(priv);
if (ret)
- goto error_free_netdev;
+ goto error_hw_init;
ndev->netdev_ops = &stmmac_netdev_ops;
@@ -2768,12 +2773,6 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
goto error_netdev_register;
}
- priv->stmmac_clk = clk_get(priv->device, STMMAC_RESOURCE_NAME);
- if (IS_ERR(priv->stmmac_clk)) {
- pr_warn("%s: warning: cannot get CSR clock\n", __func__);
- goto error_clk_get;
- }
-
/* If a specific clk_csr value is passed from the platform
* this means that the CSR Clock Range selection cannot be
* changed at run-time and it is fixed. Viceversa the driver'll try to
@@ -2801,12 +2800,12 @@ struct stmmac_priv *stmmac_dvr_probe(struct device
*device,
return priv;
error_mdio_register:
- clk_put(priv->stmmac_clk);
-error_clk_get:
unregister_netdev(ndev);
error_netdev_register:
netif_napi_del(&priv->napi);
-error_free_netdev:
+error_hw_init:
+ clk_disable_unprepare(priv->stmmac_clk);
+error_clk_get:
free_netdev(ndev);
return NULL;
@@ -2833,6 +2832,7 @@ int stmmac_dvr_remove(struct net_device *ndev)
stmmac_mdio_unregister(ndev);
netif_carrier_off(ndev);
unregister_netdev(ndev);
+ clk_disable_unprepare(priv->stmmac_clk);
free_netdev(ndev);
return 0;
--
1.8.5.2
--
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/groups/opt_out.
[linux-sunxi] [PATCH net-next v3 8/8] net: stmmac: sunxi platform extensions for GMAC in Allwinner A20 SoC's
The Allwinner A20 has an ethernet controller that seems to be
an early version of Synopsys DesignWare MAC 10/100/1000 Universal,
which is supported by the stmmac driver.
Allwinner's GMAC requires setting additional registers in the SoC's
clock control unit.
The exact version of the DWMAC IP that Allwinner uses is unknown,
thus the exact feature set is unknown.
Signed-off-by: Chen-Yu Tsai
---
.../bindings/net/allwinner,sun7i-a20-gmac.txt | 27
drivers/net/ethernet/stmicro/stmmac/Kconfig| 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 141 +
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +
6 files changed, 186 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
new file mode 100644
index 000..ea4d752
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
@@ -0,0 +1,27 @@
+* Allwinner GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+ - compatible: Should be "allwinner,sun7i-a20-gmac"
+ - clocks: Should contain the GMAC main clock, and tx clock
+ The tx clock type should be "allwinner,sun7i-a20-gmac-clk"
+ - clock-names: Should contain the clock names "stmmaceth",
+ and "allwinner_gmac_tx"
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Examples:
+
+ gmac: ethernet@01c5 {
+ compatible = "allwinner,sun7i-a20-gmac";
+ reg = <0x01c5 0x1>,
+ <0x01c20164 0x4>;
+ interrupts = <0 85 1>;
+ interrupt-names = "macirq";
+ clocks = <&ahb_gates 49>, <&gmac_tx>;
+ clock-names = "stmmaceth", "allwinner_gmac_tx";
+ phy-mode = "mii";
+ };
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index b59d1ef..e2f202e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -26,6 +26,17 @@ config STMMAC_PLATFORM
If unsure, say N.
+config DWMAC_SUNXI
+ bool "Allwinner GMAC support"
+ depends on STMMAC_PLATFORM && ARCH_SUNXI
+ default y
+ ---help---
+ Support for Allwinner A20/A31 GMAC ethernet controllers.
+
+ This selects Allwinner SoC glue layer support for the
+ stmmac device driver. This driver is used for A20/A31
+ GMACethernet controller.
+
config STMMAC_PCI
bool "STMMAC PCI bus support"
depends on STMMAC_ETH && PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 356a9dd..ecadece 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_STMMAC_ETH) += stmmac.o
stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
+stmmac-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
new file mode 100644
index 000..dc4f8ae
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
@@ -0,0 +1,141 @@
+/**
+ * dwmac-sunxi.c - Allwinner sunxi DWMAC specific glue layer
+ *
+ * Copyright (C) 2013 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct sunxi_priv_data {
+ int interface;
+ int clk_enabled;
+ struct clk *tx_clk;
+ struct regulator *regulator;
+};
+
+static void *sun7i_gmac_setup(struct platform_device *pdev)
+{
+ struct sunxi_priv_data *gmac;
+ struct device *dev = &pdev->dev;
+
+ gmac = devm_kzalloc(dev, sizeof(*gmac), GFP_KERNEL);
+ if (!g
[linux-sunxi] [PATCH net-next v3 6/8] net: stmmac: Deprecate snps,phy-addr and auto-detect PHY address
The snps,phy-addr device tree property is non-standard, and should be removed in favor of proper phy node support. Remove it from the binding documents and warn if the property is still used. Most PHYs respond to address 0, but a few don't, so auto-detect PHY address by default, to make up for the lack of explicit address selection. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/net/stmmac.txt | 1 - drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 9 - 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index d132513..aefb639 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -12,7 +12,6 @@ Required properties: property - phy-mode: String, operation mode of the PHY interface. Supported values are: "mii", "rmii", "gmii", "rgmii". -- snps,phy-addrphy address to connect to. - snps,reset-gpio gpio number for phy reset. - snps,reset-active-low boolean flag to indicate if phy reset is active low. - snps,reset-delays-us is triplet of delays diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index 634260e..82110f1 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -50,7 +50,14 @@ static int stmmac_probe_config_dt(struct platform_device *pdev, if (plat->bus_id < 0) plat->bus_id = 0; - of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr); + /* Default to phy auto-detection */ + plat->phy_addr = -1; + + /* "snps,phy-addr" is not a standard property. Mark it as deprecated +* and warn of its use. Remove this when phy node support is added. +*/ + if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0) + dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n"); plat->mdio_bus_data = devm_kzalloc(&pdev->dev, sizeof(struct stmmac_mdio_bus_data), -- 1.8.5.2 -- 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/groups/opt_out.
Re: [linux-sunxi] [PATCH] Fix K1001L1C LCD bug
On 13-01-14 00:51, Korneliusz Osmenda wrote: Fex file for tablet didn't specified pll3 setting which caused nonworking LCD. --- sys_config/a20/k1001l1c.fex | 1 + 1 file changed, 1 insertion(+) diff --git a/sys_config/a20/k1001l1c.fex b/sys_config/a20/k1001l1c.fex index 54ac2c7..b11d75e 100644 --- a/sys_config/a20/k1001l1c.fex +++ b/sys_config/a20/k1001l1c.fex @@ -16,6 +16,7 @@ power_start = 0 storage_type = -1 [clock] +pll3 = 297 pll4 = 300 pll6 = 600 pll7 = 297 applied, thanks oliver -- 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/groups/opt_out.
[linux-sunxi] RE: [PATCH RFC 1/6] net: rfkill: gpio: fix gpio name buffer size off by 1
From: Chen-Yu Tsai > snprintf should be passed the complete size of the buffer, including > the space for '\0'. The previous code resulted in the *_reset and > *_shutdown strings being truncated. ... > diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c ... > - snprintf(rfkill->reset_name, len + 6 , "%s_reset", rfkill->name); > - snprintf(rfkill->shutdown_name, len + 9, "%s_shutdown", rfkill->name); > + snprintf(rfkill->reset_name, len + 7 , "%s_reset", rfkill->name); > + snprintf(rfkill->shutdown_name, len + 10, "%s_shutdown", rfkill->name); I can't find the context for the above, but they look very dubious. I'd expect: snprintf(foo, sizeof foo, ...). If you are trying to truncate rfkill->name you need to use %.*s. David -- 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/groups/opt_out.
[linux-sunxi] Re: LCD output on A20 Android 4.2.2
You can use pure SDK 1.2 to build android os. Then you can control the video output to LCD. Download from : http://dl.linux-sunxi.org/users/tsvetan/A20-SDK-V1.2/A20-V1.2.tar.gz -- 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/groups/opt_out.
Re: [linux-sunxi] 24-bit Audio Isn't Working
I don't think anybody here has tested this yet either. So any findings are very welcome! Oliver On 13-01-14 05:29, George Ioakimedes wrote: We've been looking into supporting high resolution audio file playback, specifically 24-bit/96kHz and 24-bit/192kHz files. We've made some changes and had a little progress but are still not able to get proper playback of 24-bit audio files. I'm hoping that by posting here someone else has looked at this or has some ideas of what is needed to get this working. We've confirmed with Allwinner that it should work but that it was never tested. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Doing some sunxi hacking in Brussels the Friday before Fosdem ?
Just an FYI to the hacking session; while it sounds like a lot of fun and something really cool I could learn a lot from, I won't be able to schedule that in at all. To bad FOSDEM is so awesome and there are so many interesting talks! So sat/sun is out of the question. Oliver On 14-01-14 14:28, Benjamin Henrion wrote: On Tue, Jan 14, 2014 at 1:29 PM, Zoltan HERPAI wrote: On Tue, 14 Jan 2014, Ian Campbell wrote: On Tue, 2014-01-14 at 11:49 +0100, Luc Verhaegen wrote: On Tue, Jan 14, 2014 at 10:19:36AM +, Ian Campbell wrote: It sound cool! I'm arriving at Brussels Midi at 1405 on Friday afternoon. I'm not sure if I'll have other Xen/work related commitments that afternoon though. Would it be OK to just rock up, assuming you get enough confirmed interest to go ahead? So you go from midi to your hotel and check-in and stuff... Add the 30 or so minutes commute from the gare centrale... You will be at the ulb at 16:00 at the earliest. Around 16:30 you might finally sit down and "have a hacking session". There was talk of hacking until ~2000, which is 3.5hrs, plenty of time to get some useful stuff done IMHO. I'd also expect to be there more like 1500-1530 in any case. Assuming it goes ahead of course. I plan to arrive in Brussels around noon, so once settled in the hotel I could get to the place in the afternoon. Benjamin, do you have any costs with this? Event is free, but urlab sells some drinks and food. They are also interested in geek stickers, if you have some good ones. And they also accept donations... -- 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/groups/opt_out.
Re: [linux-sunxi] [PATCH u-boot-sunxi] ARM: sunxi: get script.bin file name from env
Pat,
Thanks, Pushed this now.
Yeah it doesn't hurt having it available as an env at all. I don't think
it matters greatly for having it in mainline, if everything is cleaned
up, passing script.bin or dtb is up to the user, so it may as well fly.
Oliver
On 09-01-14 06:49, Patrick Wood wrote:
All the other files can be overridden by env settings, what's so
special about script.bin?
Use the "script" env variable instead of hard-coding script.bin
everywhere; still defaults to "script.bin", but can be overridden
from uEnv.txt or boot.scr.
Signed-off-by: Patrick Wood
---
include/configs/sunxi-common.h |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 2c86a8e..a0c41ac 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -213,6 +213,7 @@
"kernel=uImage\0" \
"bootenv=uEnv.txt\0" \
"bootscr=boot.scr\0" \
+ "script=script.bin\0" \
"loadbootscr=" \
"fatload $device $partition $scriptaddr ${bootscr}" \
" || " \
@@ -231,19 +232,19 @@
"if "\
"bootpath=/boot/" \
" && " \
- "ext2load $device $partition 0x4300 ${bootpath}script.bin" \
+ "ext2load $device $partition 0x4300 ${bootpath}${script}" \
" && " \
"ext2load $device $partition 0x4800 ${bootpath}${kernel}" \
";then true; elif " \
"bootpath=/" \
" && " \
- "fatload $device $partition 0x4300 script.bin" \
+ "fatload $device $partition 0x4300 ${script}" \
" && " \
"fatload $device $partition 0x4800 ${kernel}" \
";then true; elif " \
"bootpath=/" \
" && " \
- "ext2load $device $partition 0x4300 ${bootpath}script.bin" \
+ "ext2load $device $partition 0x4300 ${bootpath}${script}" \
" && " \
"ext2load $device $partition 0x4800 ${bootpath}${kernel}" \
";then true; else "\
--
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/groups/opt_out.
[linux-sunxi] Re: [PATCH] ARM: sunxi: change the AllWinner A1X to sunxi
Hi Arnd, On Wed, Jan 15, 2014 at 10:40:56AM +0100, Arnd Bergmann wrote: > On Wednesday 15 January 2014 10:10:06 Maxime Ripard wrote: > > On Thu, Jan 09, 2014 at 04:34:04PM +0100, Gerardo Di Iorio wrote: > > > Change the AllWinner A1X SOCs to Allwinner Sunxi SOCs > > > > > > Signed-off-by: Gerardo Di Iorio > > > --- > > > arch/arm/mach-sunxi/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > > > index 547004c..adb2574 100644 > > > --- a/arch/arm/mach-sunxi/Kconfig > > > +++ b/arch/arm/mach-sunxi/Kconfig > > > @@ -1,5 +1,5 @@ > > > config ARCH_SUNXI > > > - bool "Allwinner A1X SOCs" if ARCH_MULTI_V7 > > > + bool "Allwinner Sunxi SOCs" if ARCH_MULTI_V7 > > > > I wonder if the sunxi (apart the weird letter case) is actually > > needed. Maybe we can just put "Allwinner SoCs" (it would be great if > > you could fix the SoCs case too). > > If you want to have exact naming, try to find something that excludes the > old Sun3i (F20) and earlier chips (unless someone is already planning > to work on them). Maybe also mention the "Boxchip" name, although that > seems to be falling out of use these days. I'm not sure that's good to exclude chips. We have a number of SoCs we don't support even on later families (A31s, A23, mostly). I'm not sure we want to have an ever growing list of SoCs supported (or not-supported). "sunXi" would be fine I guess, or "A-series" like suggested on IRC. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 2/4] ARM: sun6i: dt: Add PLL6 and SPI module clocks
Hi Josh,
On Thu, Jan 16, 2014 at 12:15:28PM -0600, Josh Cartwright wrote:
> On Thu, Jan 16, 2014 at 06:11:23PM +0100, Maxime Ripard wrote:
> > The module clocks in the A31 are still compatible with the A10 one. Add the
> > SPI
> > module clocks and the PLL6 in the device tree to allow their use by the SPI
> > controllers.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > arch/arm/boot/dts/sun6i-a31.dtsi | 48
> > +++-
> > 1 file changed, 38 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi
> > b/arch/arm/boot/dts/sun6i-a31.dtsi
> > index 5256ad9..ae058eb 100644
> > --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> > +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> > @@ -73,16 +73,12 @@
> > clocks = <&osc24M>;
> > };
> >
> > - /*
> > -* This is a dummy clock, to be used as placeholder on
> > -* other mux clocks when a specific parent clock is not
> > -* yet implemented. It should be dropped when the driver
> > -* is complete.
> > -*/
> > - pll6: pll6 {
> > - #clock-cells = <0>;
> > - compatible = "fixed-clock";
> > - clock-frequency = <0>;
> > + pll6: clk@01c20028 {
> > + #clock-cells = <1>;
> > + compatible = "allwinner,sun6i-a31-pll6-clk";
> > + reg = <0x01c20028 0x4>;
> > + clocks = <&osc24M>;
> > + clock-output-names = "pll6";
> > };
> >
> > cpu: cpu@01c20050 {
> > @@ -182,6 +178,38 @@
> > "apb2_uart1", "apb2_uart2",
> > "apb2_uart3",
> > "apb2_uart4", "apb2_uart5";
> > };
> > +
> > + spi0_clk: clk@01c200a0 {
> > + #clock-cells = <0>;
> > + compatible = "allwinner,sun4i-mod0-clk";
> > + reg = <0x01c200a0 0x4>;
> > + clocks = <&osc24M>, <&pll6>;
>
> This looks weird. You've set the pll6 #clock-cells = <1>, but you
> aren't using a specifier here. Same below, as well. The binding
> documentation indicates that #clock-cells should be 0 for the pll6 node.
Ah, right, it's a dumb copy/paste mistake.
I'd expect dtc to output a warning/error in such case, but apparently
it doesn't.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [linux-sunxi] Sudden memory failure on an A20-OLinuXino-MICRO
On 14-01-14 19:52, Axel Theilmann wrote: You probably best contact olimex for custommer support Oliver moin, i know nothing about the specific problem, but have you checked your power supply? yes, the power supply should be ok. i have used it for months without problems. it works ok with lots of other boards (both of the same type and other models). i tried different voltage levels (the board can accept 6 - 16 Volt) and the power supply is also powerful enough. tty, axel -- 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/groups/opt_out.
Re: [linux-sunxi] Booting Android with uboot
On 15-01-14 13:15, jonsm...@gmail.com wrote: On Wed, Jan 15, 2014 at 12:44 AM, Henrik Nordström wrote: tis 2014-01-14 klockan 22:44 -0500 skrev jonsm...@gmail.com: I can boot Linux using this procedure without problem, but I can't get my Android kernel to boot. Android kernel just hangs... What is the difference between linux and an "Android kernel"? linux-sunxi.org kernel is an Android kernel. The CSI camera code in the Allwinner SDK kernel is far different than the code in sunxi kernel. I am unable to get the sunxi code working with a camera. sunxi code is losing buffers and after a few second stops because all of the buffers are lost. I started porting Allwinner CSI over but it relies on a lot of structure changes (gpio support) in the h files and that started rippling into a bunch of other code. The sunxi CSI code is old 3.0 code dropped CSI stuff; I don't think it received (m)any patches, so as usual, patches more then welcome! Oliver Does script.bin need to be somewhere else for the Android kernel to find it? I am using Android kernel from Allwinner SDK, not the sunxi one. So your question is do the Allwinner SDK kernel need script.bin in another place than the linux-sunxi.org kernel? No they expect script.bin in the same place. Regards Henrik -- 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/groups/opt_out. -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH RFC 1/6] net: rfkill: gpio: fix gpio name buffer size off by 1
On Fri, Jan 17, 2014 at 5:46 PM, David Laight wrote: > From: Chen-Yu Tsai >> snprintf should be passed the complete size of the buffer, including >> the space for '\0'. The previous code resulted in the *_reset and >> *_shutdown strings being truncated. > ... >> diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c > ... >> - snprintf(rfkill->reset_name, len + 6 , "%s_reset", rfkill->name); >> - snprintf(rfkill->shutdown_name, len + 9, "%s_shutdown", rfkill->name); >> + snprintf(rfkill->reset_name, len + 7 , "%s_reset", rfkill->name); >> + snprintf(rfkill->shutdown_name, len + 10, "%s_shutdown", rfkill->name); > > I can't find the context for the above, but they look very dubious. > I'd expect: snprintf(foo, sizeof foo, ...). > If you are trying to truncate rfkill->name you need to use %.*s. The driver allocates these buffers on the fly, a few lines above: len = strlen(rfkill->name); rfkill->reset_name = devm_kzalloc(&pdev->dev, len + 7, GFP_KERNEL); rfkill->shutdown_name = devm_kzalloc(&pdev->dev, len + 10, GFP_KERNEL); I am not trying to truncate rfkill->name. Rather, the buffer length passed to snprintf was wrong, so the resulting name was truncated by one character. Thanks, 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/groups/opt_out.
Re: [linux-sunxi] Re: How to test wifi in A20.
Hi Puneet,
bcmdhd is currently not working in the sunxi-3.4 kernel; this is known.
We will try to backport the 3.14 patches to see if that makes it work.
The cubieboard kernel's patched some stuff in but I think there's a bug
somewhere as you mention with the gpio's. I did see this document
somewhere (mailing list or some wiki; i forgot)
Oliver
On 17-01-14 08:54, Puneet B wrote:
Hi,
While tracing problem i found below issue.
i am getting error in log as:
[4.780261] [dhd_module_init] get wl_host_wake gpio failed
The code is from here:./
vim linux-sunxi/drivers/net/wireless/bcmdhd/dhd_linux.c +4396
if (gpio_request(WL_HOST_WAKE_DEF_GPIO, "wl_host_wake")) {
pr_warning("[%s] get wl_host_wake gpio failed\n",
__FUNCTION__);
wl_host_wake = -1;
return -1;
}
Which means some gpio error:
In script for wifi:
ap6xxx_wl_regon = port:PH09<1><0>
ap6xxx_wl_host_wake = port:PH10<0><0>
ap6xxx_bt_regon = port:PB05<1><0>
ap6xxx_bt_wake = port:PI20<1><0>
ap6xxx_bt_host_wake = port:PI21<0><0>
ap6xxx_lpo = port:PI12<4>
For ap6xxx_wl_host_wake , i check by making high and low but error is same.
Can any one tell why that error is, Is it because of some gpio pins or
something else went wrong?
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/groups/opt_out.
--
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/groups/opt_out.
[linux-sunxi] Re: [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
On Thu, Jan 16, 2014 at 1:39 PM, Maxime Ripard
wrote:
> Hi Carlo,
>
> On Sat, Jan 11, 2014 at 04:19:06PM +0100, Carlo Caione wrote:
>> Allwinner A20/A31 SoCs have special registers to control / (un)mask /
>> acknowledge NMI. This NMI controller is separated and independent from GIC.
>> This patch adds a new irqchip to manage NMI.
>>
>> Signed-off-by: Carlo Caione
>> ---
>> drivers/irqchip/Makefile| 1 +
>> drivers/irqchip/irq-sunxi-nmi.c | 228
>>
>> 2 files changed, 229 insertions(+)
>> create mode 100644 drivers/irqchip/irq-sunxi-nmi.c
>>
>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>> index c60b901..e31d4d6 100644
>> --- a/drivers/irqchip/Makefile
>> +++ b/drivers/irqchip/Makefile
>> @@ -11,6 +11,7 @@ obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)+= irq-metag.o
>> obj-$(CONFIG_ARCH_MOXART)+= irq-moxart.o
>> obj-$(CONFIG_ORION_IRQCHIP) += irq-orion.o
>> obj-$(CONFIG_ARCH_SUNXI) += irq-sun4i.o
>> +obj-$(CONFIG_ARCH_SUNXI) += irq-sunxi-nmi.o
>> obj-$(CONFIG_ARCH_SPEAR3XX) += spear-shirq.o
>> obj-$(CONFIG_ARM_GIC)+= irq-gic.o
>> obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
>> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
>> b/drivers/irqchip/irq-sunxi-nmi.c
>> new file mode 100644
>> index 000..a2b7373
>> --- /dev/null
>> +++ b/drivers/irqchip/irq-sunxi-nmi.c
>> @@ -0,0 +1,228 @@
>> +/*
>> + * Allwinner A20/A31 SoCs NMI IRQ chip driver.
>> + *
>> + * Carlo Caione
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include "irqchip.h"
>> +
>> +#define SUNXI_NMI_SRC_TYPE_MASK 0x0003
>> +
>> +enum {
>> + SUNXI_SRC_TYPE_LEVEL_LOW = 0,
>> + SUNXI_SRC_TYPE_EDGE_FALLING,
>> + SUNXI_SRC_TYPE_LEVEL_HIGH,
>> + SUNXI_SRC_TYPE_EDGE_RISING,
>> +};
>> +
>> +struct sunxi_sc_nmi_reg_offs {
>> + u32 ctrl;
>> + u32 pend;
>> + u32 enable;
>> +};
>> +
>> +static struct sunxi_sc_nmi_reg_offs sun7i_reg_offs = {
>> + .ctrl = 0x00,
>> + .pend = 0x04,
>> + .enable = 0x08,
>> +};
>> +
>> +static struct sunxi_sc_nmi_reg_offs sun6i_reg_offs = {
>> + .ctrl = 0x00,
>> + .pend = 0x04,
>> + .enable = 0x34,
>> +};
>> +
>> +/*
>> + * Ack level interrupts right before unmask
>> + *
>> + * In case of level-triggered interrupt, IRQ line must be acked before it
>> + * is unmasked or else a double-interrupt is triggered
>> + */
>> +
>> +static void sunxi_sc_nmi_ack_and_unmask(struct irq_data *d)
>> +{
>> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
>> + struct irq_chip_type *ct = irq_data_get_chip_type(d);
>> + u32 mask = d->mask;
>> +
>> + if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK)
>> + ct->chip.irq_ack(d);
>> +
>> + irq_gc_lock(gc);
>> + irq_reg_writel(mask, gc->reg_base + ct->regs.mask);
>> + irq_gc_unlock(gc);
>> +}
>
> Hmmm, handle_level_irq seems to be doing exactly that already. It
> first masks and acks the interrupts, and then unmask it, so we should
> be fine, don't we?
We don't, or at least handle_level_irq doesn't work for all the cases.
Let's say (i.e. this is the cubieboard2 case) that to the irqchip is
connected to the IRQ line of a PMIC accessed by I2C. In this case we
cannot mask/ack the interrupt on the originating device in the hard
interrupt handler (in which handle_level_irq is) since we need to
access the I2C bus in an non-interrupt context. ACKing the IRQ in
handle_level_irq at this point is pretty much useless since we still
have to ACK the IRQs on the originating device and this will be done
in a IRQ thread started after the hard IRQ handler.
sunxi_sc_nmi_ack_and_unmask is therefore called (by
irq_finalize_oneshot) after the IRQ thread has been executed. After
the IRQ thread has ACKed the IRQs on the originating device we can
finally ACK and unmask again the NMI.
>> +static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
>> + u32 val)
>> +{
>> + irq_reg_writel(val, gc->reg_base + off);
>> +}
>> +
>> +static inline u32 sunxi_sc_nmi_read(struct irq_chip_generic *gc, u32 off)
>> +{
>> + return irq_reg_readl(gc->reg_base + off);
>> +}
>> +
>> +static void sunxi_sc_nmi_handle_irq(unsigned int irq, struct irq_desc *desc)
>> +{
>> + struct irq_domain *domain = irq_desc_get_handler_data(desc);
>> + struct irq_chip *chip = irq_get_chip(irq);
>> + unsigned int virq = irq_find_mapping(domain, 0);
>> +
>> + chained_irq_enter(chip, desc);
>> + generic_handle_irq(virq);
>> + chained_irq_exit(chip, desc);
>> +}
>> +
>> +static int
