Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix Ethernet PHY mode
Hi, You're veering dangerously close to troll territory, but I'll give you one last response on this. On Mon, Jul 5, 2021 at 10:18 AM B.R. Oake wrote: > > On Fri Jun 04 08:49:28 CEST 2021, Julian Calaby wrote: > > While I completely sympathise with your points here, the issue isn't a > > technical or social issue, but a legal one. > > [...] > > Dear Julian, > > Thank you for giving your point of view on this issue, and sorry for not > replying sooner. Thanks also for your work on the Atheros wifi driver, > which I've used a lot. I think it's a particularly important one since > it's one of the few wireless chipsets with open firmware. > > > > The DCO was introduced to provide a mechanism to trace the origin of a > > piece of code for legal purposes, so my understanding is that the name > > supplied needs to be your legal name. > > Please could you say what you mean by "legal name"? For example, do you > consider "J.R.R. Tolkien" to be a legal name? Nope, I'd be surprised if that was his legal name. I'd expect it would have been "John Tolkien" or "John Ronald Reuel Tolkien". > Can you give an example of a legal purpose for which the DCO was > intended and which fails when the DCO is signed with a name like > G. Robinson or C.J. Newton? https://lkml.org/lkml/2004/5/23/10 is the rationale behind the DCO. The TL;DR is that SCO was claiming that code was written by them and suing people over that. The DCO was developed as a method to assign a legal origin to contributions to Linux. My understanding is that there needs to be some way to link up a piece of code with an actual physical person, so "real" / "legal" name + email was chosen as the simplest solution. My understanding is that if your name on your passport / drivers license / official id card is "B.R. Oake" then we're good, otherwise use the name that would be used in a legal document. > > Whilst, as you've pointed out, there are a lot of ways that names > > don't match up to the normal "Firstname I. N. I. T. I. A. L. S. > > Lastname" format, that is the case for the vast majority of people and > > exceptions to that are rare. > > I'm not sure about that - for example, Mandarin names don't really fit > that template. But even if exceptions were rare, would that mean those > people and their contributions didn't matter? Here's an example of someone who I believe is a Chinese national using a anglicised chinese name as their name in a patch: https://lore.kernel.org/linux-wireless/20210517050141.61488-6-shenyan...@huawei.com/ Here's another example: https://lore.kernel.org/linux-wireless/2e938041399b47ae04c6c339c6cd5cdb7786ee6b.1623912317.git.ryder@mediatek.com/ > > Your arguments against providing that > > name haven't exactly helped your case [...] > > Well I didn't actually argue against providing a name of the form you've > specified - I have no objection to authors doing that if they want to. I > just gave some reasons why an author might sign with a name of the form > J.K. Smith. When a practice is contested I believe it does help to show > that it has legitimate reasons. The first link above was found on the third search result on Bing. It's not difficult to find out why this practice has been adopted and what the reasoning behind it is. > > Your points about previous instances of this happening also don't hold > > water either as we don't know the circumstances behind those cases. > > Git's history is considered immutable once it makes it to an > > "official" repository (generally one published publicly) so it's > > likely they were oversights that weren't caught until it was too late. > > Although the history might be immutable, offending commits can still be > reverted. However, I have not found any examples of this happening to > the commits by the authors I mentioned, which suggests there is no > problem with having them. Reverting doesn't eliminate history, it just puts things back to how they were. Kinda like tidying a room the day after you messed it up instead of changing history to not mess it up at all. I don't believe that reverting is a strong enough act to fix these sorts of issues. > And I think we do know a bit about their circumstances. To take one > example, over an 18-month period I can see 72 commits authored by KP > Singh which were variously committed, signed off, acknowledged and > reviewed by Daniel Borkmann, Yonghong Song, Mimi Zohar, Alexei > Starovoitov, Andrii Nakryiko, Martin KaFai Lau, Song Liu, Florent > Revest, James Morris, Andrew Morton, Linus Torvalds, Brendan Jackman, > Thomas Garnier, Kees Cook, Casey Schaufler and Randy Dunlap. > > It doesn't seem very likely that these approvals we
Re: [linux-sunxi] Re: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix Ethernet PHY mode
Hi, On Fri, Jun 4, 2021 at 3:45 PM 'B.R. Oake' via linux-sunxi wrote: > > On Sat Feb 13 09:51:17 CET 2021, Jernej Škrabec wrote: > > Let me first explain that it was oversight on my side not noticing initials > > in > > your SoB tag. But since the issue was raised by Maxime, I didn't follow up. > > [...] > > Dear Jernej, > > First of all, thank you very much for all your linux-sunxi work: I > especially appreciate the video support you've provided. > > Thank you for initially approving my patch. Although I first posted a > patch to the linux-sunxi list about seven years ago, this patch was my > first formal submission to LKML, so it meant a lot to me to see it > accepted by a kernel developer, even if only briefly. > > I'm sorry for taking a long time to reply. I wanted to wait for the > maintainers to respond to my last mail because I thought it would be > best for them to speak for themselves on this issue. Sadly I haven't > yet received a response from them. > > > > I believe that real name means no initials, no matter what people are > > accustomed to. From my point of view, CJ is pseudonym derived from real > > name. > > I don't think that's a widely held belief though. For example, I think > most people consider "J.R.R. Tolkien" to be a real name, even though it > contains initials. Also, a first name like CJ isn't necessarily derived > from some longer name like Cathy Jane, it can simply be the person's > given name. I'm grateful to Vagrant Cascadian for drawing our attention > to Patrick McKenzie's essay "Falsehoods Programmers Believe About Names". > I believe we harm Linux development when we exclude people whose names > don't fit our assumptions. > > Another reason for signing with initials is to ensure that other people > cannot infer anything about the author's gender. Women especially might > choose to do this to avoid the harassment that a female name can attract, > as shown in these studies for example: > > https://ece.umd.edu/news/story/study-finds-femalename-chat-users-get-25-times-more-malicious-messages > https://www.reach3insights.com/women-gaming-study > > If we forbid people from contributing in a gender-neutral way, many may > feel they cannot contribute at all. Again, I think that when we exclude > these people we are all worse off as a result. While I completely sympathise with your points here, the issue isn't a technical or social issue, but a legal one. The DCO was introduced to provide a mechanism to trace the origin of a piece of code for legal purposes, so my understanding is that the name supplied needs to be your legal name. Whilst, as you've pointed out, there are a lot of ways that names don't match up to the normal "Firstname I. N. I. T. I. A. L. S. Lastname" format, that is the case for the vast majority of people and exceptions to that are rare. Your arguments against providing that name haven't exactly helped your case either as they are similar to the arguments someone trying to hide behind a pseudonym might use. Your points about previous instances of this happening also don't hold water either as we don't know the circumstances behind those cases. Git's history is considered immutable once it makes it to an "official" repository (generally one published publicly) so it's likely they were oversights that weren't caught until it was too late. 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAGRGNgVSze9yW6KTsC%3DKGCVOJLzck65J-f9v8y30iBw7k0KXQA%40mail.gmail.com.
Re: [linux-sunxi] [PATCH v2 2/9] power: supply: axp20x_ac_power: Fix reporting online status
Hi Samuel,
On Sun, Jan 5, 2020 at 12:24 PM Samuel Holland wrote:
>
> AXP803/AXP813 have a flag that enables/disables the AC power supply
> input. This flag does not affect the status bits in PWR_INPUT_STATUS.
> Its effect can be verified by checking the battery charge/discharge
> state (bit 2 of PWR_INPUT_STATUS), or by examining the current draw on
> the AC input.
>
> Take this flag into account when getting the ONLINE property of the AC
> input, on PMICs where this flag is present.
>
> Fixes: 7693b5643fd2 ("power: supply: add AC power supply driver for AXP813")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Samuel Holland
> ---
> drivers/power/supply/axp20x_ac_power.c | 31 +-
> 1 file changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/power/supply/axp20x_ac_power.c
> b/drivers/power/supply/axp20x_ac_power.c
> index 0d34a932b6d5..ca0a28f72a27 100644
> --- a/drivers/power/supply/axp20x_ac_power.c
> +++ b/drivers/power/supply/axp20x_ac_power.c
> @@ -23,6 +23,8 @@
> #define AXP20X_PWR_STATUS_ACIN_PRESENT BIT(7)
> #define AXP20X_PWR_STATUS_ACIN_AVAIL BIT(6)
>
> +#define AXP813_ACIN_PATH_SEL BIT(7)
> +
> #define AXP813_VHOLD_MASK GENMASK(5, 3)
> #define AXP813_VHOLD_UV_TO_BIT(x) x) / 10) - 40) << 3)
> #define AXP813_VHOLD_REG_TO_UV(x) \
> @@ -40,6 +42,7 @@ struct axp20x_ac_power {
> struct power_supply *supply;
> struct iio_channel *acin_v;
> struct iio_channel *acin_i;
> + bool has_acin_path_sel;
> };
>
> static irqreturn_t axp20x_ac_power_irq(int irq, void *devid)
> @@ -86,6 +89,17 @@ static int axp20x_ac_power_get_property(struct
> power_supply *psy,
> return ret;
>
> val->intval = !!(reg & AXP20X_PWR_STATUS_ACIN_AVAIL);
> +
> + /* ACIN_PATH_SEL disables ACIN even if ACIN_AVAIL is set. */
> + if (power->has_acin_path_sel) {
Do we need to check this bit if ACIN_AVAIL is not set?
> + ret = regmap_read(power->regmap,
> AXP813_ACIN_PATH_CTRL,
> + );
> + if (ret)
> + return ret;
> +
> + val->intval &= !!(reg & AXP813_ACIN_PATH_SEL);
If we only check this bit if ACIN_AVAIL is set, then we don't need the
"&" in the "&=". (I'm assuming that val->intval is an int, not a bool,
otherwise this is the wrong operator)
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAGRGNgXeenNYMNXY0dewQaeG2QecUPgE_MOofURg7HzcND782w%40mail.gmail.com.
Re: [linux-sunxi] [PATCH v3 03/11] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
Hi Ondrej
On Thu, Apr 11, 2019 at 8:19 PM megous via linux-sunxi
wrote:
>
> From: Ondrej Jirman
>
> H6 has a different I/O voltage bias setting method than A80. Prepare
> existing code for using alternative bias voltage setting methods.
>
> Signed-off-by: Ondrej Jirman
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index ee15ab067b5f..4bfc8a6d9dce 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -95,6 +95,13 @@
> #define PINCTRL_SUN7I_A20 BIT(7)
> #define PINCTRL_SUN8I_R40 BIT(8)
>
> +enum sunxi_desc_bias_voltage {
> + BIAS_VOLTAGE_NONE,
> + /* Bias voltage configuration is done through
> +* Pn_GRP_CONFIG registers, as seen on A80 SoC. */
> + BIAS_VOLTAGE_GRP_CONFIG,
> +};
> +
> struct sunxi_desc_function {
> unsigned long variant;
> const char *name;
> @@ -117,7 +124,7 @@ struct sunxi_pinctrl_desc {
> const unsigned int *irq_bank_map;
> boolirq_read_needs_mux;
> booldisable_strict_mode;
> - boolhas_io_bias_cfg;
> + int io_bias_cfg_variant;
Shouldn't we be defining this field using the enum rather than as an int?
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.
Re: [linux-sunxi] [PATCH 1/3] arm: sunxi: Allow per-platform DRAM ZQ configuration on sun8i
Hi Paul, On Thu, Mar 14, 2019 at 9:37 PM Paul Kocialkowski wrote: > > A few sun8i platforms define specific default DRAM ZQ values, but they > are not taken in account because of MACH_SUN8I being used for the 123 > default first. > > Replace MACH_SUN8I with the list of platforms that don't have specific > DRAM ZQ values, to avoid overwriting the default for those that do. > > Signed-off-by: Paul Kocialkowski > --- > arch/arm/mach-sunxi/Kconfig | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 74e234cded75..c557c79ef097 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -414,7 +414,9 @@ endif > > config DRAM_ZQ > int "sunxi dram zq value" > - default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I > + default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || \ > + MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_A83T || > \ > + MACH_SUNXI_H3_H5 > default 127 if MACH_SUN7I > default 14779 if MACH_SUN8I_V3S > default 3881979 if MACH_SUN8I_R40 || MACH_SUN50I_H6 Would it work if these were just re-ordered so the more specific ones come first? 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.
Re: [linux-sunxi] [PATCH 2/8] regulator: axp20x: add support for set_ramp_delay for AXP209
Hi Priit and Olliver,
On Tue, Dec 11, 2018 at 5:42 AM Priit Laes wrote:
>
> From: Olliver Schinagl
>
> The AXP209 supports ramping up voltages on several regulators such as
> DCDC2 and LDO3.
>
> This patch adds preliminary support for the regulator-ramp-delay property
> for these 2 regulators. Note that the voltage ramp only works when
> regulator is already enabled. E.g. when going from say 0.7 V to 3.6 V.
>
> When turning on the regulator, no voltage ramp is performed in hardware.
>
> What this means, is that if the bootloader brings up the voltage at 0.7 V,
> the ramp delay property is properly applied. If however, the bootloader
> leaves the power off, no ramp delay is applied when the power is
> enabled by the regulator framework.
>
> Signed-off-by: Olliver Schinagl
> Signed-off-by: Priit Laes
> ---
> drivers/regulator/axp20x-regulator.c | 85 +-
> 1 file changed, 85 insertions(+)
>
> diff --git a/drivers/regulator/axp20x-regulator.c
> b/drivers/regulator/axp20x-regulator.c
> index 9a2db28..1d9fa62 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -346,6 +357,79 @@
> .ops= _ops_range,
> \
> }
>
> +static const int axp209_dcdc2_ldo3_slew_rates[] = {
> + 1600,
> +800,
> +};
> +
> +static int axp20x_set_ramp_delay(struct regulator_dev *rdev, int ramp)
> +{
> + struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
> + const struct regulator_desc *desc = rdev->desc;
> + u8 reg, mask, enable, cfg = 0xff;
> + const int *slew_rates;
> + int rate_count = 0;
> +
> + if (!rdev)
> + return -EINVAL;
> +
> + switch (axp20x->variant) {
> + case AXP209_ID:
> + if (desc->id == AXP20X_DCDC2) {
Is slew_rates supposed to be set here?
> + rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
> + reg = AXP20X_DCDC2_LDO3_V_RAMP;
> + mask = AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_RATE_MASK |
> + AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN_MASK;
> + enable = (ramp > 0) ?
> +AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN :
> +!AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN;
> + break;
> + }
> +
> + if (desc->id == AXP20X_LDO3) {
> + slew_rates = axp209_dcdc2_ldo3_slew_rates;
> + rate_count = ARRAY_SIZE(axp209_dcdc2_ldo3_slew_rates);
> + reg = AXP20X_DCDC2_LDO3_V_RAMP;
> + mask = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE_MASK |
> + AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN_MASK;
> + enable = (ramp > 0) ?
> +AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN :
> +!AXP20X_DCDC2_LDO3_V_RAMP_LDO3_EN;
> + break;
> + }
> +
> + if (rate_count > 0)
> + break;
You could save one to two tests by combining the above three if statements, i.e.
if (DCDC2) {
// set DCDC2 stuff
break;
} else if (LDO3) {
// set LDO3 stuff
break;
}
As written, the rate_count > 0 test will never be true as every block
that sets rate_count breaks out of the switch block.
You could then calculate rate_count below the switch block.
> +
> + /* fall through */
> + default:
> + /* Not supported for this regulator */
> + return -ENOTSUPP;
> + }
> +
> + if (ramp == 0) {
> + cfg = enable;
> + } else {
> + int i;
> +
> + for (i = 0; i < rate_count; i++) {
> + if (ramp <= slew_rates[i])
> + cfg = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(i);
> + else
> + break;
> + }
> +
> + if (cfg == 0xff) {
> + dev_err(axp20x->dev, "unsupported ramp value %d",
> ramp);
> + return -EINVAL;
> + }
> +
> + cfg |= enable;
> + }
> +
> + return regmap_update_bits(axp20x->regmap, reg, mask, cfg);
> +}
> +
--
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.
Re: [linux-sunxi] Re: [PATCH v3 17/25] dt-bindings: panel: Add Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB bridge
Hi Jagan, On Wed, Oct 31, 2018 at 7:58 PM Chen-Yu Tsai wrote: > > On Wed, Oct 31, 2018 at 4:53 PM Andrzej Hajda wrote: > > > > On 26.10.2018 16:43, Jagan Teki wrote: > > > Bananapi S070WV20-CT16 ICN6211 is 800x480, 4-lane MIPI-DSI to RGB > > > bridge panel, which is available on same PCB with 24-bit RGB interface. > > > > > > So, this patch adds DSI specific binding details on existing > > > dt-bindings file. > > > > > > Signed-off-by: Jagan Teki > > > --- > > > Changes for v3: > > > - Use existing binding doc and update dsi details > > > Changes for v2: > > > - none > > > > > > .../display/panel/bananapi,s070wv20-ct16.txt | 31 +-- > > > 1 file changed, 29 insertions(+), 2 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > > > > > b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > > index 35bc0c839f49..b7855dc7c66f 100644 > > > --- > > > a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > > +++ > > > b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > > @@ -1,12 +1,39 @@ > > > Banana Pi 7" (S070WV20-CT16) TFT LCD Panel > > > > > > +S070WV20-CT16 is 7" 800x480 panel connected through a 24-bit RGB > > > interface. > > > + > > > +Depending on the variant, the PCB attached to the panel module either > > > +supports DSI, or DSI + 24-bit RGB. DSI is converted to 24-bit RGB via > > > +an onboard ICN6211 MIPI DSI - RGB bridge chip, then fed to the panel > > > +itself > > > > As I understand this is display board, which contains 'pure' RGB panel > > S070WV20-CT16 and optionally ICN6211 DSI->RGB bridge. > > These are separate devices, just connected by vendor to simplify its > > assembly. Why don't you create then bridge driver for ICN6211 and RGB > > panel driver for S070WV20-CT16 - it looks more generic. > > Then you can describe both in dts and voila. > > Creating drivers for every combo of devices (panel + bridge), just > > because some vendor sells them together seems incorrect - we have > > devicetree for it. > > Rob suggested this, and also the opposite: using the same > "bananapi,s070wv20-ct16" > compatible string for both types of connections, and have the driver deal with > detecting the bus type. > > The thing about the bridge chip is that there's no available datasheet that > describes all the parts of the init sequence, in fact none at all. I managed > to work out some bits, but the others remain a mystery and must be hard-coded > to match the panel. That would work against having a generic bridge driver. To me it seems logical that we'd model it as another step in the graph between the DSI component and the panel. It's conceivable that some other manufacturer will probably buy these for their panels and having a somewhat generic driver seems vaguely future proof to me. As I see it, the weird init process belongs to the bridge chip and the timings belong to the panel and we shouldn't "confuse" them by giving them the same compatible. That said, I'm sure that these chips are already old hat and we'll have something different and even more incomprehensible next week. 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.
Re: [linux-sunxi] [PATCH 10/15] drm/sun4i: Add support for R40 TV TCONs
Hi Jernej,
On Sun, May 20, 2018 at 11:57 AM, Julian Calaby <julian.cal...@gmail.com> wrote:
> Hi Jernej,
>
> On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec <jernej.skra...@siol.net>
> wrote:
>> R40 display pipeline has a lot of possible configurations. HDMI can be
>> connected to 2 different TCONs (out of 4) and mixers can be connected to
>> any TCON. All this must be configured in TCON TOP.
>>
>> Along with definition of TCON capabilities also add mux callback, which
>> can configure this complex pipeline.
>>
>> For now, only TCON TV is supported.
>>
>> Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net>
>> ---
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 39 ++
>> 1 file changed, 39 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index e0c562ce1c22..81b9551e4f78 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -1274,6 +1274,31 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
>> return 0;
>> }
>>
>> +static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
>> +const struct drm_encoder *encoder,
>> +int index)
>> +{
>> + if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
>> + sun8i_tcon_top_set_hdmi_src(tcon->tcon_top, index);
>> +
>> + sun8i_tcon_top_de_config(tcon->tcon_top, tcon->id,
>> +tcon_type_tv, index);
>> +
>> + return 0;
>> +}
>> +
>> +static int sun8i_r40_tcon_tv_set_mux_0(struct sun4i_tcon *tcon,
>> + const struct drm_encoder *encoder)
>> +{
>> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 0);
>> +}
>> +
>> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_tcon *tcon,
>> + const struct drm_encoder *encoder)
>> +{
>> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
>> +}
>
> Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
> If so, maybe we should add an index to the TCON quirks and have a
> common TCON-TOP set_mux function.
Actually, that only moves it up a level. Should it be a devicetree property?
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.
Re: [linux-sunxi] [PATCH 10/15] drm/sun4i: Add support for R40 TV TCONs
Hi Jernej,
On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec <jernej.skra...@siol.net> wrote:
> R40 display pipeline has a lot of possible configurations. HDMI can be
> connected to 2 different TCONs (out of 4) and mixers can be connected to
> any TCON. All this must be configured in TCON TOP.
>
> Along with definition of TCON capabilities also add mux callback, which
> can configure this complex pipeline.
>
> For now, only TCON TV is supported.
>
> Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 39 ++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index e0c562ce1c22..81b9551e4f78 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1274,6 +1274,31 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
> return 0;
> }
>
> +static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
> +const struct drm_encoder *encoder,
> +int index)
> +{
> + if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
> + sun8i_tcon_top_set_hdmi_src(tcon->tcon_top, index);
> +
> + sun8i_tcon_top_de_config(tcon->tcon_top, tcon->id,
> +tcon_type_tv, index);
> +
> + return 0;
> +}
> +
> +static int sun8i_r40_tcon_tv_set_mux_0(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 0);
> +}
> +
> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
> +}
Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
If so, maybe we should add an index to the TCON quirks and have a
common TCON-TOP set_mux function.
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.
Re: [linux-sunxi] [PATCH 07/15] dt-bindings: display: sun4i-drm: Add R40 HDMI pipeline
Hi Jernej, On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec <jernej.skra...@siol.net> wrote: > Missing compatibles and descriptions needed to implement R40 HDMI > pipeline are added. > > For mixers only compatibles are added. > > TCON description is expanded with R40 TV TCON compatibles. If the SoC > has TCON TOP unit, phandle to that unit has to be specified. Additional > clock has to be specified if SoC has TCON TOP and TCON is TV TCON. > > New compatible is added for DWC HDMI PHY, which has additional clock > specified. There's a bunch of A64 related stuff mixed in here, is the R40 compatible with the A64's parts? If so, you should probably mention that in the commit log. > Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net> > --- > .../bindings/display/sunxi/sun4i-drm.txt | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > index a099957ab62a..634276f713e8 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -111,8 +112,9 @@ Required properties: >- resets: phandle to the reset controller driving the PHY >- reset-names: must be "phy" > > -H3 HDMI PHY requires additional clock: > +H3 and A64 HDMI PHY requires additional clocks: >- pll-0: parent of phy clock > + - pll-1: second possible phy clock parent (A64 only) Maybe split this into two: H3 HDMI PHY ... - pll-0: ... A64 HDMI PHY ... - pll-0: ... - pll-1: ... At the moment a quick reading implies that H3 needs pll-1. 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.
Re: [linux-sunxi] [PATCH v2 1/6] ASoC: sun4i-i2s: Add slot width override
Hi Marcus, On Tue, Mar 13, 2018 at 2:57 AM, <codekip...@gmail.com> wrote: > From: Marcus Cooper <codekip...@gmail.com> > > Some codecs require a different amount of a bit clocks per frame > than what is calculated by using the sample width. Use a slot > width override property to provide this mechanism. > > Signed-off-by: Marcus Cooper <codekip...@gmail.com> > --- > Documentation/devicetree/bindings/sound/sun4i-i2s.txt | 5 + > sound/soc/sunxi/sun4i-i2s.c | 15 --- > 2 files changed, 17 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > index b9d50d6cdef3..48addef65b8f 100644 > --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > @@ -28,6 +28,11 @@ Required properties for the following compatibles: > - "allwinner,sun8i-h3-i2s" > - resets: phandle to the reset line for this codec > > +Optional properties: > +- allwinner,slot-width-override:if this property is present then the dai is > + configured to extend the slot width to the > + value specified. Min 8, Max 32. > + This sounds like something that would be useful for other I2S controllers. 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.
Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards
Hi Maxime, On Tue, Feb 27, 2018 at 6:07 PM, Maxime Ripard <maxime.rip...@bootlin.com> wrote: > On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote: >> Hi Jernej, >> >> On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec <jernej.skra...@siol.net> >> wrote: >> > Hi, >> > >> > Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng >> > napisal(a): >> >> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec" >> > <jernej.skra...@siol.net> 写到: >> >> >Hi Julian, >> >> > >> >> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby >> >> > >> >> >napisal(a): >> >> >> Hi Jernej, >> >> >> >> >> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec >> >> > >> >> ><jernej.skra...@siol.net> >> >> > >> >> >wrote: >> >> >> > Enable HDMI output on all boards which have HDMI connector. >> >> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net> >> >> >> > --- >> >> >> > >> >> >> > arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25 >> >> >> > ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts >> >> >> > >> >> >> > | 25 ++ >> >> >> > >> >> >> > arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25 >> >> >> > ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts >> >> >> > >> >> >> > | 25 ++ >> >> > >> >> >arch/arm/boot/dts/sun8i-h3-orangepi-2.dts >> >> > >> >> >> > | 25 ++ >> >> >> > >> >> >> > arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts | 25 >> >> >> > ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts >> >> >> > >> >> >> > | 24 + >> >> > >> >> >arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >> >> > >> >> >> >| 25 ++ 8 files changed, 199 >> >> > >> >> >insertions(+) >> >> > >> >> >> As I understand it, the H2+ is just a slightly trimmed down H3. In >> >> >> terms of HDMI support, the difference is that the H2+ can't output >> >> > >> >> >4k. >> >> > >> >> >> If this code is compatible with the H2+, could you please add the >> >> >> necessary bits and pieces to the h2-plus DTSs too? >> >> > >> >> >There are only 3 H2+ boards in kernel and none of them has HDMI >> >> >connector, so >> >> >> >> BPi M2 Zero has miniHDMI connector. >> > >> > Ah, sorry, I missed that one. Since I don't have it (or any other board >> > with >> > H2+) I'm not really comfortable including such patch. If anyone will test >> > it, >> > I can include it in next revision. >> >> I have one of those (this is why I'm interested in this patchset) so >> I'm willing to test, however I can't guarantee I'll get to it quickly. > > Then I guess the best way forward will be to keep the current patch as > is, and you'll send a patch whenever you have the time to test it. Fair enough, I'll do that then. =) 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.
Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards
Hi Jernej, On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec <jernej.skra...@siol.net> wrote: > Hi, > > Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng napisal(a): >> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec" > <jernej.skra...@siol.net> 写到: >> >Hi Julian, >> > >> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby >> > >> >napisal(a): >> >> Hi Jernej, >> >> >> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec >> > >> ><jernej.skra...@siol.net> >> > >> >wrote: >> >> > Enable HDMI output on all boards which have HDMI connector. >> >> > >> >> > Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net> >> >> > --- >> >> > >> >> > arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25 >> >> > ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts >> >> > >> >> > | 25 ++ >> >> > >> >> > arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25 >> >> > ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts >> >> > >> >> > | 25 ++ >> > >> >arch/arm/boot/dts/sun8i-h3-orangepi-2.dts >> > >> >> > | 25 ++ >> >> > >> >> > arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts | 25 >> >> > ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts >> >> > >> >> > | 24 + >> > >> >arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts >> > >> >> >| 25 ++ 8 files changed, 199 >> > >> >insertions(+) >> > >> >> As I understand it, the H2+ is just a slightly trimmed down H3. In >> >> terms of HDMI support, the difference is that the H2+ can't output >> > >> >4k. >> > >> >> If this code is compatible with the H2+, could you please add the >> >> necessary bits and pieces to the h2-plus DTSs too? >> > >> >There are only 3 H2+ boards in kernel and none of them has HDMI >> >connector, so >> >> BPi M2 Zero has miniHDMI connector. > > Ah, sorry, I missed that one. Since I don't have it (or any other board with > H2+) I'm not really comfortable including such patch. If anyone will test it, > I can include it in next revision. I have one of those (this is why I'm interested in this patchset) so I'm willing to test, however I can't guarantee I'll get to it quickly. 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.
Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards
Hi Icenowy, On Sun, Feb 25, 2018 at 7:43 PM, Icenowy Zheng <icen...@aosc.io> wrote: > > > 于 2018年2月25日 GMT+08:00 下午4:11:34, Julian Calaby <julian.cal...@gmail.com> 写到: >>Hi Jernej, >> >>On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec >><jernej.skra...@siol.net> wrote: >>> Enable HDMI output on all boards which have HDMI connector. >>> >>> Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net> >>> --- >>> arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25 >>++ >>> arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 25 >>++ >>> arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25 >>++ >>> arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 25 >>++ >>> arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 25 >>++ >>> arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts | 25 >>++ >>> arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 24 >>+ >>> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 25 >>++ >>> 8 files changed, 199 insertions(+) >> >>As I understand it, the H2+ is just a slightly trimmed down H3. In >>terms of HDMI support, the difference is that the H2+ can't output 4k. > > H2+ can OUTPUT 4K. The BSP restricts it to DECODE 4K. (And mainline won't > have such restriction) Interesting! I'm getting my data from here: http://linux-sunxi.org/H3#Variants So essentially what you're saying is that the H2+ is just a H3 with less pins? (I'm assuming the "lack of gigabit mac" is effectively it not having the required pins, i.e. GPIO bank D) 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.
Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards
Hi Jernej, On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec <jernej.skra...@siol.net> wrote: > Enable HDMI output on all boards which have HDMI connector. > > Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net> > --- > arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25 > ++ > arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 25 > ++ > arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25 > ++ > arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 25 > ++ > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 25 > ++ > arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts | 25 > ++ > arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 24 + > arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 25 > ++ > 8 files changed, 199 insertions(+) As I understand it, the H2+ is just a slightly trimmed down H3. In terms of HDMI support, the difference is that the H2+ can't output 4k. If this code is compatible with the H2+, could you please add the necessary bits and pieces to the h2-plus DTSs too? 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.
Re: [linux-sunxi] [PATCH v3] rtc: ac100: Fix ac100 determine rate bug
Hi Phillipp,
On Thu, Feb 15, 2018 at 12:56 AM, Philipp Rossak <embe...@gmail.com> wrote:
> This patch fixes a bug, that prevents the Allwinner A83T and the A80
> from a successful boot.
>
> The bug is there since v4.16-rc1 and appeared after the clk branch was
> merged.
>
> You can find the shortend trace below:
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
> pgd = (ptrval)
> [] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be #2
> Hardware name: Allwinner sun8i Family
> Workqueue: events deferred_probe_work_func
> PC is at clk_hw_get_rate+0x0/0x34
> LR is at ac100_clkout_determine_rate+0x48/0x19c
>
> [ ... ]
>
> (clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
> (ac100_clkout_determine_rate) from (clk_core_set_rate_nolock+0x3c/0x1a0)
> (clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
> (clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
> (of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)
>
> To fix that bug, we first check if the return of the
> clk_hw_get_parent_by_index is non zero. If it is zero we skip that
> clock parent.
>
> The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198
>
> Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support")
>
> Signed-off-by: Philipp Rossak <embe...@gmail.com>
> ---
>
> Changes in v3:
> * add information when the bug appeared
> * make the comment more clear
> Changes in v2:
> * add tag Fixes: ... to commit message
> * add comment to if statement why we are doing this check
>
> drivers/rtc/rtc-ac100.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
> index 8ff9dc3fe5bf..2412aa2e8399 100644
> --- a/drivers/rtc/rtc-ac100.c
> +++ b/drivers/rtc/rtc-ac100.c
> @@ -183,7 +183,24 @@ static int ac100_clkout_determine_rate(struct clk_hw *hw,
>
> for (i = 0; i < num_parents; i++) {
> struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
> - unsigned long tmp, prate = clk_hw_get_rate(parent);
> + unsigned long tmp, prate;
> +
> + /*
> +* The clock has two parents, one is a fixed clock which is
> +* internally registered by the ac100 driver. The other parent
> +* is a clock from the codec side of the chip, which we
> +* properly declare and reference in the devicetree and is
> +* not implemented in any driver right now.
> +* If the clock core looks for the parent of that second
> +* missing clock, it can't one that is registered and
You've missed the word "find" between "it can't" and "one that is registered".
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.
Re: [linux-sunxi] [PATCH v3] ARM: sun8i: h2+: add support for Banana Pi M2 Zero board
Hi Maxime, On Tue, Feb 6, 2018 at 7:29 PM, Maxime Ripard <maxime.rip...@bootlin.com> wrote: > On Tue, Feb 06, 2018 at 10:51:04AM +0800, Icenowy Zheng wrote: >> 于 2018年2月5日 GMT+08:00 下午9:36:25, Maxime Ripard <maxime.rip...@bootlin.com> >> 写到: >> >On Sat, Feb 03, 2018 at 05:45:52PM +1100, Julian Calaby wrote: >> >> Hi all, >> >> >> >> On Sun, Dec 24, 2017 at 4:40 PM, Icenowy Zheng <icen...@aosc.io> >> >wrote: >> >> > Banana Pi M2 Zero board is a H2+-based board by Sinovoip, with a >> >form >> >> > factor and GPIO holes similar to Raspberry Pi Zero. >> >> > >> >> > It features: >> >> > - Allwinner H2+ SoC >> >> > - Single-chip (16-bit) 512MiB DDR3 DRAM >> >> > - Ampak AP6212 Wi-Fi/Bluetooth module >> >> > - MicroSD slot >> >> > - Two MicroUSB Type-B ports (one can only be used to power the >> >board and >> >> > the other features OTG functionality) >> >> > - Two keys, a reset and a GPIO-connected key. >> >> > - HDMI Type-C (miniHDMI) connector connected to the HDMI part of >> >H2+. >> >> > - CSI connector to connect the camera sensor provided by Sinovoip. >> >> > >> >> > Signed-off-by: Icenowy Zheng <icen...@aosc.io> >> >> >> >> [Trimmed lots of non-sunxi-specific mailing lists] >> >> >> >> Did support for this board ever get merged? >> > >> >It doesn't look like it did. >> >> Is there any problem in this patch now except the >> absense of SPDX license usage? > > Doesn't look like it. Awesome, I'll get it booting, fix the licence block and re-submit. I'll also put together patches to add the HDMI and DVFS bits and send them as those features make it upstream. I was worried that I'd have to figure out the WiFi stuff, however Icenowy has already done that. Thanks! 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.
Re: [linux-sunxi] [PATCH v3] ARM: sun8i: h2+: add support for Banana Pi M2 Zero board
Hi all, On Sun, Dec 24, 2017 at 4:40 PM, Icenowy Zheng <icen...@aosc.io> wrote: > Banana Pi M2 Zero board is a H2+-based board by Sinovoip, with a form > factor and GPIO holes similar to Raspberry Pi Zero. > > It features: > - Allwinner H2+ SoC > - Single-chip (16-bit) 512MiB DDR3 DRAM > - Ampak AP6212 Wi-Fi/Bluetooth module > - MicroSD slot > - Two MicroUSB Type-B ports (one can only be used to power the board and > the other features OTG functionality) > - Two keys, a reset and a GPIO-connected key. > - HDMI Type-C (miniHDMI) connector connected to the HDMI part of H2+. > - CSI connector to connect the camera sensor provided by Sinovoip. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> [Trimmed lots of non-sunxi-specific mailing lists] Did support for this board ever get merged? (I have two of them now, so if it didn't, I'll try to shepherd this and it's corresponding u-boot patch upstream.) 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.
Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one
Hi Icenowy, On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng <icen...@aosc.io> wrote: > The V3s is just a differently packaged version of the V3 chip, which has > a MAC with the same capability with H3. The V3s just doesn't wire out > the external MII/RMII/RGMII bus. (V3 wired out it). > > Drop the compatible string of V3s in the dwmac-sun8i driver, and add a > V3 compatible string, which has all capabilities. Aren't compatible strings technically API, so don't we need to support those that are out in the wild "forever"? Therefore shouldn't we leave the v3s variant around for compatibility with existing device trees? 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.
Re: [linux-sunxi] Re: [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
Hi Maxime, On Wed, Jan 31, 2018 at 7:36 PM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > Hi Julian, > > On Wed, Jan 31, 2018 at 07:29:13PM +1100, Julian Calaby wrote: >> Hi Maxime, >> >> On Wed, Jan 31, 2018 at 7:21 PM, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >> > Hi, >> > >> > On Mon, Jan 29, 2018 at 10:38:25AM +, Andre Przywara wrote: >> >> On 29/01/18 09:58, Maxime Ripard wrote: >> >> > On Mon, Jan 29, 2018 at 09:44:44AM +, Andre Przywara wrote: >> >> >> On 29/01/18 08:51, Maxime Ripard wrote: >> >> >>> On Mon, Jan 29, 2018 at 01:15:19AM +, Andre Przywara wrote: >> >> >>>> The existing sun8i-emac driver in U-Boot uses some preliminary >> >> >>>> bindings, >> >> >>>> which matched our own DTs. Now that the Linux kernel got a driver, >> >> >>>> lets >> >> >>>> update our probe code to handle those Linux DTs as well. >> >> >>>> The first patch adds the missing compatible strings for the pinctrl >> >> >>>> drivers, >> >> >>>> which is needed for using the sunxi_name_to_gpio() lookup function. >> >> >>>> Patch 2/3 updates the pinctrl parser used in the sun8i-emac driver, >> >> >>>> to cope >> >> >>>> with the new, generic Allwinner pinctrl bindings. >> >> >>>> The final patch extends the probe routine in the Ethernet driver to >> >> >>>> deal >> >> >>>> with both the old and the new bindings. >> >> >>> >> >> >>> Thanks for posting this >> >> >>> >> >> >>>> This series allows to copy in the DTs from the latest kernel. >> >> >>>> Unfortunately >> >> >>>> right now updating the DTs for the H5 and A64 breaks the build, as >> >> >>>> the >> >> >>>> resulting binary (which embeds the DT) gets to large and triggers >> >> >>>> our new >> >> >>>> image size check. >> >> >>> >> >> >>> Sigh... >> >> >>> >> >> >>>> As the H5 and H3 share most of the DT, we can't just update the H3 >> >> >>>> DTs either. Hopefully we find some neat trick to work around that. >> >> >>> >> >> >>> Is it just because of the DT size, or because there's more code? >> >> >> >> >> >> My impression the code itself is always growing a tiny bit over the >> >> >> weeks, but this time around it's really the DT update. >> >> >> The current A64 .dtbs in U-Boot are around 8KB, mainline is at 13KB. >> >> >> Similar for the H5: going from 9.5KB to 14.5KB. >> >> >> >> >> >> Since you did a pretty good job already in identifying the code hogs, I >> >> >> couldn't find *easy* mitigations over the weekend. >> >> >> One possible fix is to remove the second .dtb in the Pine64 case, for >> >> >> which I sent a patch Friday night. >> >> > >> >> > Since the DT is fed to the C preprocessor, we could also put some >> >> > #ifdef 0 around the nodes that are never used by U-Boot (like the >> >> > clocks, timer, psci, dma, GIC, RTC, RSB, etc.) >> >> >> >> Well yes, U-Boot itself actually only requires a *tiny* .dtb (I think >> >> /aliases, /chosen, the reg of USB and Ethernet). But to be honest I >> >> don't want to go there. First it would be a constant churn to keep this >> >> up-to-date, >> > >> > I'm not too worried about the churn, it would be there only for the >> > time until we fully migrate to the FAT environment, so one-two release >> > now. And we're not syncing the DT very often these days (now that we >> > have support for the EMAC and USB that is all U-Boot cares about). >> > >> >> but more importantly for proper UEFI boot we just reuse U-Boot's >> >> .dtb to pass it on to the kernel. That is actually the purpose of >> >> this whole exercise. That already works today (at least for A64), >> >> but would benefit from some updates. >> >> >> >> So I would refrain from tinkering with U-Boot's .dtbs. >> > >> > That sucks :/ >
Re: [linux-sunxi] Re: [PATCH 0/3] sunxi: sun8i-emac: Update DT bindings
gs, to avoid collateral >> damage to other boards. >> If people have a special need, they can always disable the MMC env and >> enable stuff at their likings, it's just the standard "make >> .._defconfig; make" process that needs to be fixed with some band-aids >> for now. > > I really don't want to go down the "let's fix each defconfig when we > find out it broke", this is very likely to be broken with no-one > noticing. > > Is this issue happening when you sync the whole DT, and would it break > if you just convert the EMAC binding? > > Otherwise, we might try to revive the DTC garbage collection of unused > nodes patches. This would prevent us from using the overlays on such a > DT, but that doesn't like like an unfair tradeoff. Stupid question: As I understand it, the boot process is SPL => Full U-Boot => Linux. Would it therefore be possible to use a cut-down DT for the SPL (just the bits it cares about) then use a full one afterwards? I'm guessing that the SPL wants to patch the DT we pass to Linux, would we be able to handle that using overlays? 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.
Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs
Hi Icenowy, On Sat, Jan 20, 2018 at 2:10 PM, Icenowy Zheng <icen...@aosc.io> wrote: > > > 于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby <julian.cal...@gmail.com> 写到: >>Hi Icenowy, >> >>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng <icen...@aosc.io> >>wrote: >>> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die >>used >>> for many new F-series products, including F1C100A, F1C100s, F1C200s, >>> F1C500, F1C600). >>> >>> Signed-off-by: Icenowy Zheng <icen...@aosc.io> >>> --- >>> arch/arm/mach-sunxi/Kconfig| 13 + >>> arch/arm/mach-sunxi/Makefile | 1 + >>> arch/arm/mach-sunxi/sunxi_v5.c | 22 ++ >>> 3 files changed, 36 insertions(+) >>> create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c >>> >>> diff --git a/arch/arm/mach-sunxi/Kconfig >>b/arch/arm/mach-sunxi/Kconfig >>> index 65509a35935f..78ac9ce70641 100644 >>> --- a/arch/arm/mach-sunxi/Kconfig >>> +++ b/arch/arm/mach-sunxi/Kconfig >>> @@ -59,3 +59,16 @@ config MACH_SUN9I >>> select ARM_GIC >>> >>> endif >>> + >>> +menuconfig ARCH_SUNXI_V5 >>> + bool "Allwinner SoCs" >> >>That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"? > > This is already required by armv5. > > Allwinner currently has only ARMv5,7,8 SoCs. ARMv8 is under > arm64 architecture, and ARMv5 and v7 cannot be selected at the same time. I'm going to try to back my way out of this hole by saying that they should be more descriptive anyway (and it'll give clueless kconfiggers a hint as to why they're not seeing their SoC listed) However you're right, if both cannot be visible at the same time, then it really doesn't matter if they both have the same name. Sorry for the noise, -- 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.
Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs
Hi Icenowy, On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng <icen...@aosc.io> wrote: > Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die used > for many new F-series products, including F1C100A, F1C100s, F1C200s, > F1C500, F1C600). > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > --- > arch/arm/mach-sunxi/Kconfig| 13 + > arch/arm/mach-sunxi/Makefile | 1 + > arch/arm/mach-sunxi/sunxi_v5.c | 22 ++ > 3 files changed, 36 insertions(+) > create mode 100644 arch/arm/mach-sunxi/sunxi_v5.c > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 65509a35935f..78ac9ce70641 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -59,3 +59,16 @@ config MACH_SUN9I > select ARM_GIC > > endif > + > +menuconfig ARCH_SUNXI_V5 > + bool "Allwinner SoCs" That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"? 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.
Re: [linux-sunxi] [RFC PATCH 1/9] ARM: add CONFIG_ARCH_SUNXI_V7 for differentiate ARMv5/v7 Allwinner SoCs
Hi Icenowy, On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng <icen...@aosc.io> wrote: > Allwinner also has some ARMv5 SoCs. > > In order to add support for them, add a CONFIG_ARCH_SUNXI_V7 option that > is selectable when ARMv7 is selceted, and make CONFIG_ARCH_SUNXI a > common bool config which is selected by both V7 and V5 sunxi option. > > The ARMv7 defconfigs are modified to have the new CONFIG_ARCH_SUNXI_V7 > option. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > --- > arch/arm/configs/multi_v7_defconfig | 2 +- > arch/arm/configs/sunxi_defconfig| 2 +- > arch/arm/mach-sunxi/Kconfig | 14 -- > arch/arm/mach-sunxi/Makefile| 2 +- > 4 files changed, 15 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 58153cdf025b..65509a35935f 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -1,6 +1,16 @@ > -menuconfig ARCH_SUNXI > +config ARCH_SUNXI > + bool > + select ARCH_HAS_RESET_CONTROLLER > + select CLKSRC_MMIO > + select GENERIC_IRQ_CHIP > + select GPIOLIB > + select PINCTRL > + select RESET_CONTROLLER > + > +menuconfig ARCH_SUNXI_V7 > bool "Allwinner SoCs" > depends on ARCH_MULTI_V7 > + select ARCH_SUNXI > select ARCH_HAS_RESET_CONTROLLER > select CLKSRC_MMIO > select GENERIC_IRQ_CHIP Shouldn't you remove all the common ARCH_SUNXI selects from ARCH_SUNXI_v7? 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.
Re: [linux-sunxi] [PATCH v2 13/16] power: supply: axp20x_battery: add support for AXP813
Hi Quentin, On Tue, Jan 9, 2018 at 8:33 PM, Quentin Schulz <quentin.sch...@free-electrons.com> wrote: > The X-Powers AXP813 PMIC has got some slight differences from > AXP20X/AXP22X PMICs: > - the maximum voltage supplied by the PMIC is 4.35 instead of 4.36/4.24 > for AXP20X/AXP22X, > - the constant charge current formula is different, > > It also has a bit to tell whether the battery percentage returned by the > PMIC is valid. > > Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com> > --- > drivers/power/supply/axp20x_battery.c | 42 - > 1 file changed, 42 insertions(+) > > diff --git a/drivers/power/supply/axp20x_battery.c > b/drivers/power/supply/axp20x_battery.c > index d73c78f..dad72a5 100644 > --- a/drivers/power/supply/axp20x_battery.c > +++ b/drivers/power/supply/axp20x_battery.c > @@ -46,6 +46,8 @@ > #define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5) > #define AXP20X_CHRG_CTRL1_TGT_4_36V(3 << 5) > > +#define AXP813_CHRG_CTRL1_TGT_4_35V(3 << 5) > + > #define AXP22X_CHRG_CTRL1_TGT_4_22V(1 << 5) > #define AXP22X_CHRG_CTRL1_TGT_4_24V(3 << 5) Should these be "alphabetical", i.e. AXP20X, AXP22X, AXP813? 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.
Re: [linux-sunxi] [PATCH 11/17] drm/sun4i: Wire in DE2 scaler support
Hi Jernej,
On Tue, Nov 28, 2017 at 7:57 AM, Jernej Skrabec <jernej.skra...@siol.net> wrote:
> Calculate scaling parameters and call appropriate scaler set up
> function.
>
> Signed-off-by: Jernej Skrabec <jernej.skra...@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun8i_layer.c | 12 +++-
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 115
> +---
> drivers/gpu/drm/sun4i/sun8i_mixer.h | 4 --
> 3 files changed, 90 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_layer.c
> index e1b6ad82145e..6860271e5415 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
> @@ -41,9 +44,14 @@ static int sun8i_mixer_layer_atomic_check(struct drm_plane
> *plane,
> clip.x2 = crtc_state->adjusted_mode.hdisplay;
> clip.y2 = crtc_state->adjusted_mode.vdisplay;
>
> + scaler_supported = !!(layer->mixer->cfg->scaler_mask &
> BIT(layer->id));
> +
> + min_scale = scaler_supported ? 1 : DRM_PLANE_HELPER_NO_SCALING;
> + max_scale = scaler_supported ? (1UL << 20) - 1 :
> + DRM_PLANE_HELPER_NO_SCALING;
> +
Disclaimer: I hate ternaries, but this looks like it'd be better
written as an if statement. I.e.
min_scale = DRM_PLANE_HELPER_NO_SCALING;
max_scale = DRM_PLANE_HELPER_NO_SCALING;
if (layer->mixer->cfg->scaler_mask & BIT(layer->id)) {
min_scale = 1;
max_scale = (1UL << 20) - 1;
}
However the compiler will probably sort it all out anyway, so it
probably doesn't matter that much, except for style.
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.
Re: [linux-sunxi] rtl8188eu driver and hostapd
Hi Ishraq, On Tue, Nov 14, 2017 at 9:24 PM, Ishraq Ibne Ashraf <ishraq.i.ash...@gmail.com> wrote: > Hi, > > In our system we use the hostapd release version 2.6 from, > https://w1.fi/cgit/hostap/snapshot/hostap_2_6.tar.bz2. > Everything works fine with the kernel and rtl8188eu driver from sunxi-next > branch with repo state, 3c2993b8c6143d8a5793746a54eba8f86f95240f (Linux > 4.12-rc4). > But doesn't work with repo state, 569dbb88e80deb68974ef6fdd6a13edb9d686261 > (Linux 4.13). > > Both the hostapd configuration and the debug output from hostapd are > attached with this post. > > When the problem occurs hostapd outputs, ioctl[RTL_IOCTL_HOSTAPD]: Operation > not supported. > Maybe there was some changes in the IOCTL interface of the driver/kernel? > > Any help is appreciated. This list is about Allwinner SoCs and the boards they are on, your question appears to be WiFi related, so you'll be more likely to get a useful answer on the linux-wireless list, which I've added to CC. 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. # AP netdevice name (without 'ap' postfix, i.e., wlan0 uses wlan0ap for # management frames with the Host AP driver); wlan0 with many nl80211 drivers. interface=wlx40a5efd82c16 # Hostapd driver to use to manage the interface. # Note: This option is only valid for newer hostapd version. # For older version this parameter is not defined. driver=rtl871xdrv # SSID to be used in IEEE 802.11 management frames. ssid=RED Brick 4.13 KRACK FIX # Channel number (IEEE 802.11) # (default: 0, i.e., not set) # Please note that some drivers do not use this value from hostapd and the # channel will need to be configured separately with iwconfig. # # If CONFIG_ACS build option is enabled, the channel can be selected # automatically at run time by setting channel=acs_survey or channel=0, both of # which will enable the ACS survey based algorithm. channel=8 # Station MAC address -based authentication # Please note that this kind of access control requires a driver that uses # hostapd to take care of management frame processing and as such, this can be # used with driver=hostap or driver=nl80211, but not with driver=atheros. # 0 = accept unless in deny list # 1 = deny unless in accept list # 2 = use external RADIUS server (accept/deny lists are searched first) macaddr_acl=0 # IEEE 802.11 specifies two authentication algorithms. hostapd can be # configured to allow both of these or only one. Open system authentication # should be used with IEEE 802.1X. # Bit fields of allowed authentication algorithms: # bit 0 = Open System Authentication # bit 1 = Shared Key Authentication (requires WEP) auth_algs=1 # Send empty SSID in beacons and ignore probe request frames that do not # specify full SSID, i.e., require stations to know SSID. # default: disabled (0) # 1 = send empty (length=0) SSID in beacon and ignore probe request for # broadcast SSID # 2 = clear SSID (ASCII 0), but keep the original length (this may be required # with some clients that do not support empty SSID) and ignore probe # requests for broadcast SSID ignore_broadcast_ssid=0 # Enable WPA. Setting this variable configures the AP to require WPA (either # WPA-PSK or WPA-RADIUS/EAP based on other configuration). For WPA-PSK, either # wpa_psk or wpa_passphrase must be set and wpa_key_mgmt must include WPA-PSK. # Instead of wpa_psk / wpa_passphrase, wpa_psk_radius might suffice. # For WPA-RADIUS/EAP, ieee8021x must be set (but without dynamic WEP keys), # RADIUS authentication server must be configured, and WPA-EAP must be included # in wpa_key_mgmt. # This field is a bit field that can be used to enable WPA (IEEE 802.11i/D3.0) # and/or WPA2 (full IEEE 802.11i/RSN): # bit0 = WPA # bit1 = IEEE 802.11i/RSN (WPA2) (dot11RSNAEnabled) wpa=2 # WPA pre-shared keys for WPA-PSK. This can be either entered as a 256-bit # secret in hex format (64 hex digits), wpa_psk, or as an ASCII passphrase # (8..63 characters) that will be converted to PSK. This conversion uses SSID # so the PSK changes when ASCII passphrase is used and the SSID is changed. # wpa_psk (dot11RSNAConfigPSKValue) # wpa_passphrase (dot11RSNAConfigPSKPassPhrase) wpa_passphrase=red-brick42 # Set of accepted key management algorithms (WPA-PSK, WPA-EAP, or both). The # entries are separated with a space. WPA-PSK-SHA256 and WPA-EAP-SHA256 can be # added to enable SHA256-based stronger algorithms. # (dot11RSNAConfigAuthenticationSuitesTable) wpa_key_mgmt=WPA-PSK # Set of accepted cipher suites (encryption algorithms) for pairwise keys # (unicast packets).
Re: [linux-sunxi] [PATCH v4 02/11] drm/sun4i: tcon: Add support for demuxing TCON output on A31
Hi Chen-Yu, On Tue, Oct 10, 2017 at 2:19 PM, Chen-Yu Tsai <w...@csie.org> wrote: > On systems with 2 TCONs such as the A31, it is possible to demux the > output of the TCONs to one encoder. > > Add support for this for the A31. > > Signed-off-by: Chen-Yu Tsai <w...@csie.org> Thanks! FWIW this is: Reviewed-by: Julian Calaby <julian.cal...@gmail.com> -- 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.
Re: [linux-sunxi] Re: [PATCH v3 04/14] drm/sun4i: tcon: Add support for demuxing TCON output on A31
Hi Chen-Yu, On Sat, Sep 30, 2017 at 3:58 PM, Chen-Yu Tsai <w...@csie.org> wrote: > On Sat, Sep 30, 2017 at 1:35 PM, Julian Calaby <julian.cal...@gmail.com> > wrote: >> Hi Chen-Yu, >> >> On Fri, Sep 29, 2017 at 8:22 PM, Chen-Yu Tsai <w...@csie.org> wrote: >>> On Fri, Sep 29, 2017 at 6:20 PM, Maxime Ripard >>> <maxime.rip...@free-electrons.com> wrote: >>>> On Fri, Sep 29, 2017 at 08:22:56AM +, Chen-Yu Tsai wrote: >>>>> On systems with 2 TCONs such as the A31, it is possible to demux the >>>>> output of the TCONs to one encoder. >>>>> >>>>> Add support for this for the A31. >>>>> >>>>> Signed-off-by: Chen-Yu Tsai <w...@csie.org> >>>>> --- >>>>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 38 >>>>> ++ >>>>> 1 file changed, 38 insertions(+) >>>>> >>>>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>>> index 7bf51abaee97..c949309d4285 100644 >>>>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>>>> @@ -112,6 +112,21 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon >>>>> *tcon, bool enable) >>>>> } >>>>> EXPORT_SYMBOL(sun4i_tcon_enable_vblank); >>>>> >>>>> +static struct sun4i_tcon *sun4i_get_first_tcon(struct drm_device *drm) >>>> >>>> Would that make sense to make it a bit more generic, and pass the id >>>> to look for as an argument? >>> >>> The reason to look for TCON0 explicitly is to access the muxing registers, >>> which >>> are only available in TCON0. Other than that, there's nothing else >>> shared between >>> the two TCONs. So there's no particular reason to look for TCON1 explicitly. >> >> In that case: in the bizarre case where we're trying to use this mux >> type and there is no TCON0, shouldn't we fail? > > It gives out a big warning, indicating something is wrong. If TCON0 is not > found > it is most likely your device tree is broken. There's nothing more the > driver can do. > Are you suggesting to return NULL in this case, and also do error > handling in the > callers? You're already returning -EINVAL for other failure cases, so a lack of TCON0 might as well do the same. >> (Also, the code doesn't make sense if we have some TCON1 and TCON2 in >> that order as it'll return TCON2) > > I'm guessing you want it to return NULL. I'm just pointing out the mismatch between getting the "first" TCON and the actual behaviour. 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.
Re: [linux-sunxi] Re: [PATCH v3 04/14] drm/sun4i: tcon: Add support for demuxing TCON output on A31
Hi Chen-Yu, On Fri, Sep 29, 2017 at 8:22 PM, Chen-Yu Tsai <w...@csie.org> wrote: > On Fri, Sep 29, 2017 at 6:20 PM, Maxime Ripard > <maxime.rip...@free-electrons.com> wrote: >> On Fri, Sep 29, 2017 at 08:22:56AM +, Chen-Yu Tsai wrote: >>> On systems with 2 TCONs such as the A31, it is possible to demux the >>> output of the TCONs to one encoder. >>> >>> Add support for this for the A31. >>> >>> Signed-off-by: Chen-Yu Tsai <w...@csie.org> >>> --- >>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 38 >>> ++ >>> 1 file changed, 38 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c >>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>> index 7bf51abaee97..c949309d4285 100644 >>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c >>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c >>> @@ -112,6 +112,21 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, >>> bool enable) >>> } >>> EXPORT_SYMBOL(sun4i_tcon_enable_vblank); >>> >>> +static struct sun4i_tcon *sun4i_get_first_tcon(struct drm_device *drm) >> >> Would that make sense to make it a bit more generic, and pass the id >> to look for as an argument? > > The reason to look for TCON0 explicitly is to access the muxing registers, > which > are only available in TCON0. Other than that, there's nothing else > shared between > the two TCONs. So there's no particular reason to look for TCON1 explicitly. In that case: in the bizarre case where we're trying to use this mux type and there is no TCON0, shouldn't we fail? (Also, the code doesn't make sense if we have some TCON1 and TCON2 in that order as it'll return TCON2) 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.
Re: [linux-sunxi] [PATCH 3/4] arm64: allwinner: h5: add compatible string for DE2 CCU
Hi Icenowy,
On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng <icen...@aosc.io> wrote:
> The DE2 CCU on Allwinner H5 SoC has a slightly different behavior than
> the one on H3, so the compatible string is not set in the common DTSI
> file.
>
> Add the compatible string of H5 DE2 CCU in H5 DTSI file.
>
> Signed-off-by: Icenowy Zheng <icen...@aosc.io>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> index d9a720bff05d..e237c05cfdb4 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> @@ -98,6 +98,10 @@
> compatible = "allwinner,sun50i-h5-ccu";
> };
>
> +_clocks {
> + compatible = "allwinner,sun50i-h5-de2-clk";
> +};
> +
This is what I get for reviewing before reading the full patch set.
Shouldn't this be rolled into the previous patch?
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.
Re: [linux-sunxi] [PATCH 2/4] ARM: sun8i: h3/h5: add DE2 CCU device node for H3
Hi Icenowy,
On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng <icen...@aosc.io> wrote:
> The DE2 in H3/H5 has a clock control unit in it, and the behavior is
> slightly different between H3 and H5.
>
> Add the common parts in H3/H5 DTSI, and add the compatible string in H3
> DTSI.
>
> The compatible string of H5 DE2 CCU will be added in a separated patch.
>
> Signed-off-by: Icenowy Zheng <icen...@aosc.io>
> ---
> arch/arm/boot/dts/sun8i-h3.dtsi| 4
> arch/arm/boot/dts/sunxi-h3-h5.dtsi | 14 ++
> 2 files changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 11240a8313c2..76a4cbc99bdb 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -85,6 +87,18 @@
> #size-cells = <1>;
> ranges;
>
> + display_clocks: clock@100 {
> + /* compatible is in per SoC .dtsi file */
I don't know device tree very well, but shouldn't this node be
disabled so that it doesn't do anything weird on H5? Or are nodes
without compatibles ignored?
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.
Re: [linux-sunxi] [PATCH 5/15] clk: sunxi-ng: sun5i: Export video PLLs
Hi Maxime, On Tue, Mar 7, 2017 at 7:56 PM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > The video PLLs are used directly by the HDMI controller. Export them so > that we can use them in our DT node. > > Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com> > --- > drivers/clk/sunxi-ng/ccu-sun5i.h | 6 -- > include/dt-bindings/clock/sun5i-ccu.h | 3 +++ > 2 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.h > b/drivers/clk/sunxi-ng/ccu-sun5i.h > index 8144487eb7ca..16f7aa92957e 100644 > --- a/drivers/clk/sunxi-ng/ccu-sun5i.h > +++ b/drivers/clk/sunxi-ng/ccu-sun5i.h > @@ -28,15 +28,17 @@ > #define CLK_PLL_AUDIO_4X 6 > #define CLK_PLL_AUDIO_8X 7 > #define CLK_PLL_VIDEO0 8 > -#define CLK_PLL_VIDEO0_2X 9 > + > +/* The PLL_VIDEO0_2X is exported for HDMI */ > + > #define CLK_PLL_VE 10 > #define CLK_PLL_DDR_BASE 11 > #define CLK_PLL_DDR12 > #define CLK_PLL_DDR_OTHER 13 > #define CLK_PLL_PERIPH 14 > #define CLK_PLL_VIDEO1 15 > -#define CLK_PLL_VIDEO1_2X 16 > > +/* The PLL_VIDEO0_2X is exported for HDMI */ PLL_VIDEO*1*_2X, right? > /* The CPU clock is exported */ > > #define CLK_AXI18 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.
Re: [linux-sunxi] [PATCH] Add the Allwinner A31/A31s PWM driver.
er will do something like this internally so there should be no performance benefit. > + struct sunxi_reg_ops *reg_ops = data->ops; > + const u32 *prescaler_table = data->prescaler_table; > u32 prd, dty, val, clk_gate; > u64 clk_rate, div = 0; > unsigned int prescaler = 0; > @@ -319,6 +454,7 @@ static int sun4i_pwm_probe(struct platform_device *pdev) > u32 val; > int i, ret; > const struct of_device_id *match; > + struct sunxi_reg_ops *reg_ops = NULL; No need to initialise this, you overwrite it unconditionally. > > match = of_match_device(sun4i_pwm_dt_ids, >dev); > 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.
Re: [linux-sunxi] Re: [PATCH 1/2] nvmem: sunxi-sid: add support for H3 and A64's SID controller
Hi Maxime,
On Fri, Jan 27, 2017 at 7:17 PM, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> Hi,
>
> On Thu, Jan 26, 2017 at 07:33:44PM +0800, Icenowy Zheng wrote:
>> H3 and A64 SoCs have a bigger SID controller, which has its direct read
>> address at 0x200 position in the SID block, not 0x0.
>>
>> Also, H3 SID controller has some silicon bug that makes the direct read
>> value wrong at first, add code to workaround the bug. (This bug has
>> already been fixed on A64 and later SoCs)
>>
>> Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
>> ---
>> .../bindings/nvmem/allwinner,sunxi-sid.txt | 22 +++-
>> drivers/nvmem/sunxi_sid.c | 112
>> +++--
>> 2 files changed, 123 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
>> index 1567ccca8de3..2e327a66a938 100644
>> --- a/drivers/nvmem/sunxi_sid.c
>> +++ b/drivers/nvmem/sunxi_sid.c
>> @@ -20,10 +20,28 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>>
>> +/* Registers and special values for doing register-based SID readout on H3
>> */
>> +#define SUN8I_SID_PRCTL 0x40
>> +#define SUN8I_SID_RDKEY 0x60
>> +
>> +#define SUN8I_SID_OP_LOCK0xAC
>> +#define SUN8I_SID_OFFSET_MASK0x1FF
>> +#define SUN8I_SID_OFFSET_SHIFT 16
>> +#define SUN8I_SID_LOCK_SHIFT 8
>> +#define SUN8I_SID_READ BIT(1)
>> +
>> +/*
>> + * For newer SoCs with a larger eFUSE, the bytes beyond the first 16 bytes
>> are
>> + * sparse, which makes it not suitable for adding randomness; legacy SoCs'
>> SID
>> + * have only 16 bytes, so we choose to use at most 16 bytes to add
>> randomness.
>> + */
>> +#define SUNXI_SID_MAX_RANDOMNESS_SIZE16
>> +
>> static struct nvmem_config econfig = {
>> .name = "sunxi-sid",
>> .read_only = true,
>> @@ -91,16 +167,17 @@ static int sunxi_sid_probe(struct platform_device *pdev)
>> if (IS_ERR(nvmem))
>> return PTR_ERR(nvmem);
>>
>> - randomness = kzalloc(sizeof(u8) * (size), GFP_KERNEL);
>> + randomness_size = max(size, SUNXI_SID_MAX_RANDOMNESS_SIZE);
>> + randomness = kzalloc(sizeof(u8) * (randomness_size), GFP_KERNEL);
>
> Why is that change needed?
According to the definition of SUNXI_SID_MAX_RANDOMNESS_SIZE, only the
first 16 bytes of the SID data region are sufficiently non-zero to be
used for randomness.
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.
Re: [linux-sunxi] Support for various sdio wifi-chips on Allwinner tablets and SBCs
Hi All, On Mon, Aug 8, 2016 at 5:25 AM, Hans de Goede <j.w.r.dego...@gmail.com> wrote: > Hi All, > > Recently I've been working on getting the sdio-wifi, found on > many a23 / a33 tablets as well as on some a10s hdmi sticks and > on various h3 SBCs such as the Orange Pi, to work with the > mainline kernel. > > If you use my sunxi-wip kernel branch (which has some dts bits > to enable this as well as some misc. bits, which I'm all > trying to get upstream) together with one of the following > out of tree drivers, you should be able to get your wifi to > work. > > ESP8089 > --- > git clone https://github.com/jwrdegoede/esp8089.git > git checkout -B cleanup origin/cleanup > cd ../linux > make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnu- modules M=../esp8089 > CONFIG_ESP8089=m > > Do not forget to copy firmware/*.bin to /lib/firmware/ on > the target system. > > Many thanks to Icenowy for her work on the esp8089 driver. The popular ESP8266 microcontrollers that have become rather popular recently are rebranded ESP8089s. If you want to test this driver and lack a board with one built in, here are some instructions on using ESP-03 boards as an SDIO WiFi card on a Raspberry Pi: https://hackaday.io/project/8678-rpi-wifi This project eventually evolved into a RasPi hat, however the initial instructions should be usable with any development board with exposed SDIO lines by anyone who isn't afraid of fine-pitch soldering. 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.
Re: [linux-sunxi] [PATCH 2/9] mfd: axp20x: Add support for AXP806 PMIC
Hi Chen-Yu, On Sun, Aug 21, 2016 at 12:11 PM, Chen-Yu Tsai <w...@csie.org> wrote: > The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80 > SoC, along with a master AXP809 PMIC. The first "AXP809" should be "AXP806". 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.
Re: [linux-sunxi] [PATCH 2/2] ASoC: sunxi: compatibility for sun6i to SPDIF
Hi Marcus,
On Sun, Jul 31, 2016 at 12:27 AM, <codekip...@gmail.com> wrote:
> From: Marcus Cooper <codekip...@gmail.com>
>
> The A31 SoC uses the same SPDIF block as found in earlier SoCs, but its
> reset is controlled via a separate reset controller.
>
> The DMA also complains when the maxburst is set to 4 so it's been adjusted
> to 8 which suites both the older and newer SoCs.
>
> Signed-off-by: Marcus Cooper <codekip...@gmail.com>
> ---
> sound/soc/sunxi/sun4i-spdif.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> index 0b04fb0..88fbb3a 100644
> --- a/sound/soc/sunxi/sun4i-spdif.c
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -482,11 +485,23 @@ static int sun4i_spdif_probe(struct platform_device
> *pdev)
> }
>
> host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
> - host->dma_params_tx.maxburst = 4;
> + host->dma_params_tx.maxburst = 8;
> host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>
> platform_set_drvdata(pdev, host);
>
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun6i-a31-spdif")) {
Given how much Allwinner likes to shuffle stuff around with each SoC
generation, would it make sense to add a flag for this in some
compatible specific config structure instead of checking against the
compatible?
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.
Re: [linux-sunxi] [PATCH] regulator: axp20x: support AXP813 variant
Hi All,
On Thu, Jul 28, 2016 at 5:28 PM, Jean-Francois Moine <moin...@free.fr> wrote:
> The X-Powers AXP813 PMIC is close enough to the AXP809 with some
> more outputs.
>
> Signed-off-by: Jean-Francois Moine <moin...@free.fr>
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 32 -
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 3 +
> drivers/regulator/axp20x-regulator.c | 82
> +++-
> include/linux/mfd/axp20x.h | 38 +++
> 5 files changed, 153 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/axp20x-regulator.c
> b/drivers/regulator/axp20x-regulator.c
> index 6d9ac76..c3287c9 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -467,7 +543,8 @@ static int axp20x_regulator_probe(struct platform_device
> *pdev)
> * name.
> */
> if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
> - (regulators == axp809_regulators && i == AXP809_DC1SW)) {
> + (regulators == axp809_regulators && i == AXP809_DC1SW) ||
> + (regulators == axp813_regulators && i == AXP813_DC1SW)) {
Are we getting to the point now where we need some other way to flag
these? Maybe a set of flags per regulator?
> new_desc = devm_kzalloc(>dev, sizeof(*desc),
> GFP_KERNEL);
> *new_desc = regulators[i];
> @@ -505,7 +582,8 @@ static int axp20x_regulator_probe(struct platform_device
> *pdev)
> * Save AXP22X DCDC1 / DCDC5 regulator names for later.
> */
> if ((regulators == axp22x_regulators && i == AXP22X_DCDC1) ||
> - (regulators == axp809_regulators && i == AXP809_DCDC1))
> + (regulators == axp809_regulators && i == AXP809_DCDC1) ||
> + (regulators == axp813_regulators && i == AXP813_DCDC1))
Ditto.
> of_property_read_string(rdev->dev.of_node,
> "regulator-name",
> _name);
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.
Re: [linux-sunxi] [PATCH] rtc-sunxi: Allow to select RTC clock source
Hi Chen-Yu, On Thu, Jul 28, 2016 at 1:22 PM, Chen-Yu Tsai <w...@csie.org> wrote: > On Thu, Jul 28, 2016 at 11:20 AM, Julian Calaby <julian.cal...@gmail.com> > wrote: >> Hi Onno, >> >> On Thu, Jul 28, 2016 at 12:58 AM, Onno Kortmann <o...@gmx.net> wrote: >>> This adds a sysfs 'clock_source' attribute which can be used to query >>> and set the clock source of the RTC, either 'internal' or 'external'. >> >> Shouldn't this also be a devicetree attribute so we can set this for >> boards we know have crystals? >> >> (Also, is there equivalent functionality for sun6i-rtc?) > > Yes there is. I'm more interested in whether boards without crystals > exist. Good point, maybe the attribute should indicate that there's no crystal and have the default be to assume there is one. Alternatively, is it possible to detect whether there's a crystal or not? 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.
Re: [linux-sunxi] [PATCH] rtc-sunxi: Allow to select RTC clock source
Hi Onno, On Thu, Jul 28, 2016 at 12:58 AM, Onno Kortmann <o...@gmx.net> wrote: > This adds a sysfs 'clock_source' attribute which can be used to query > and set the clock source of the RTC, either 'internal' or 'external'. Shouldn't this also be a devicetree attribute so we can set this for boards we know have crystals? (Also, is there equivalent functionality for sun6i-rtc?) 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.
Re: [linux-sunxi] Re: sun7i_tvd in kernel 3.4
Hi Marcus, On Thu, Jul 14, 2016 at 1:50 PM, <marcuspon...@gmail.com> wrote: > Do you think is it possible to A20 to capture simultaneously videos from four > analog video cameras through the four analog video inputs, encode them in > H.264 and record them on a SDCard ? A more important question here is whether an A20 is capable of encoding four simultaneous video streams with H.264 in real time from any source. I suspect that the answer is no. So even if the TVD driver were fully functional, you had a board with the necessary stuff to receive four analog video signals and the hardware itself is capable of receiving data from four analogue cameras simultaneously, it probably can't encode them fast enough. 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.
Re: [linux-sunxi] Re: [PATCH] mmc: pwrseq-simple: Add an optional post-power-on-delay
thout any foresight on additional needs. If we can > add a property that is more flexible, but doesn't add to the complexity > then that would be better. So this one alone is fine, but the next one > I'll be less receptive. Stupid question: In the interests of making this more flexible without adding any real "scripting", what about adding three optional delays to this binding: 1. clock delay - time from "boot" to clocks being enabled 2. reset delay - time from "boot" to resets being de-asserted 3. boot delay - time from "boot" until the mmc-pwrseq-simple driver assumes the card is ready to be probed Where the "boot" time is when the mmc-pwrseq-simple driver starts enabling this card. All three delays default to 0, the boot delay is never less than either of the other delays and the time taken to enable clocks or de-assert resets is not counted. IMHO this allows the maximum amount of flexibility (resets and clocks can be in either order) without turning this into a scripting language. I also feel that it has a nice finality about it. (Of course if you wanted to go mad and turn this into a scripting language, allowing multiple pwrseq items per card would be the simplest way to do that.) Of course this also makes everything more complicated and I'm expecting this proposal to be nak'd for obvious reasons, but I had to ask. 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.
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
Hi Kalle, On 30 Jun 2016 6:46 p.m., "Kalle Valo" <kv...@codeaurora.org> wrote: > > Arend Van Spriel <arend.vanspr...@broadcom.com> writes: > > >> Since we are dealing with a per-board config-file here, which is > >> loaded from the os filesystem we really need to specify a basename > >> here as the list of possible boards is endless, so we cannot > >> have a lookup table in the driver. > > > > As Jonas mentioned the general principle of device tree is to be > > agnostic with regards to OS and/or driver as you undoubtedly know. His > > proposal seems like a usable solution for your problem while complying > > to the device tree principle. So instead of overriding the default > > brcmfmac should modify it when dt specifies the "module" property, ie: > > > > no "module" in DT:nvram filename = brcm/brcmfmac43362-sdio.txt > > "module=ap6210" in DT:nvram filename = brcm/brcmfmac43362-ap6210.txt > > Just out of curiosity, what does "ap6210" exactly mean? I get that 43362 > is the chip id, but not ap6210. Is it just an arbitrary name? Ap6210 is a chip that contains a 43362 and probably some Bluetooth chip also. Thanks, 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.
Re: [linux-sunxi] [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One
Hi Ondrej,
On Fri, Jun 24, 2016 at 5:21 AM, <meg...@megous.com> wrote:
> From: Ondrej Jirman <meg...@megous.com>
>
> Xulong Orange Pi One uses GPIO based regulator that
> switches between two voltages: 1.1V and 1.3V. The
> regulator is controlled from the PL6 pin.
>
> Signed-off-by: Ondrej Jirman <meg...@megous.com>
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index 0adf932..ce4ba91 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -88,6 +88,25 @@
> gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
> };
> };
> +
> + vdd_soc: gpio-regulator {
> + compatible = "regulator-gpio";
> +
> + regulator-name = "soc-vdd-supply";
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <130>;
> + regulator-boot-on;
> + regulator-type = "voltage";
> +
> + gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
> + states = <110 0x0
> + 130 0x1>;
> +
> + startup-delay-us = <10>;
> + enable-active-high;
> + };
> +};
> +
Also, isn't adding another closing bracket here a syntax error?
> };
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.
Re: [linux-sunxi] [PATCH 11/14] ARM: sun8i: clk: Add clk-factor rate application method
Hi Ondrej, On Fri, Jun 24, 2016 at 5:21 AM, <meg...@megous.com> wrote: > From: Ondrej Jirman <meg...@megous.com> > > PLL1 on H3 requires special factors application algorithm, > when the rate is changed. This algorithm was extracted > from the arisc code that handles frequency scaling > in the BSP kernel. > > This commit adds optional apply function to > struct factors_data, that can implement non-trivial > factors application method, when necessary. > > Also struct clk_factors_config is extended with position > of the PLL lock flag. > > Signed-off-by: Ondrej Jirman <meg...@megous.com> > --- > arch/arm/boot/dts/sun8i-h3.dtsi | 2 +- > drivers/clk/sunxi/clk-factors.c | 34 +-- > drivers/clk/sunxi/clk-factors.h | 12 +++ > drivers/clk/sunxi/clk-sunxi.c | 72 > +++-- > 4 files changed, 98 insertions(+), 22 deletions(-) Shouldn't the .dtsi changes be in a separate patch? 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.
Re: [linux-sunxi] [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One
Hi Ondrej,
On Fri, Jun 24, 2016 at 5:21 AM, <meg...@megous.com> wrote:
> From: Ondrej Jirman <meg...@megous.com>
>
> Xulong Orange Pi One uses GPIO based regulator that
> switches between two voltages: 1.1V and 1.3V. The
> regulator is controlled from the PL6 pin.
>
> Signed-off-by: Ondrej Jirman <meg...@megous.com>
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index 0adf932..ce4ba91 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -88,6 +88,25 @@
> gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
> };
> };
> +
> + vdd_soc: gpio-regulator {
> + compatible = "regulator-gpio";
> +
> + regulator-name = "soc-vdd-supply";
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <130>;
> + regulator-boot-on;
> + regulator-type = "voltage";
> +
> + gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
> + states = <110 0x0
> + 1300000 0x1>;
> +
> + startup-delay-us = <10>;
> + enable-active-high;
Don't you need to reference the new pinctl node in this one?
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.
Re: [linux-sunxi] Call for R8 (C.H.I.P.) SID's (help needed)
Hi Maxime, On Fri, Jun 17, 2016 at 4:58 PM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Fri, Jun 17, 2016 at 03:58:44PM +1000, Julian Calaby wrote: >> Hi Maxime, >> >> On Fri, Jun 17, 2016 at 3:41 PM, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >> > On Thu, Jun 16, 2016 at 09:55:07PM +0200, Olliver Schinagl wrote: >> >> Hi maxime! >> >> >> >> So there is absolutely no way to differentiate between the 2? >> > >> > No >> >> Isn't the presence of the TV encoder on the R8 (used for the composite >> out on the CHIP) a difference between it and the regular A13? Is that >> detectable? (However I can't find any reference to it in the >> datasheet, so I'm kinda confused here.) > > The package is exactly the same, and judging from the pins, my current > guess is that it's been there all along (just like the 4 uarts and > EMAC) > > I haven't seen it wired on any A13 boards though, so it's hard to confirm. According to the CHIP schematics, it's pin #99 on the R8. Datasheets for both SoCs indicate that this pin is unused. I guess it might be instructive to try to read from the memory locations belonging to the tv output blocks specified in the R8 DTS on an A13. 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.
Re: [linux-sunxi] Call for R8 (C.H.I.P.) SID's (help needed)
Hi Maxime, On Fri, Jun 17, 2016 at 3:41 PM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Thu, Jun 16, 2016 at 09:55:07PM +0200, Olliver Schinagl wrote: >> Hi maxime! >> >> So there is absolutely no way to differentiate between the 2? > > No Isn't the presence of the TV encoder on the R8 (used for the composite out on the CHIP) a difference between it and the regular A13? Is that detectable? (However I can't find any reference to it in the datasheet, so I'm kinda confused here.) 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.
Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver
Hi Michal, On Tue, Jun 14, 2016 at 4:35 PM, Michal Suchanek <hramr...@gmail.com> wrote: > Hello, > > On 14 June 2016 at 07:45, Julian Calaby <julian.cal...@gmail.com> wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 3:28 PM, Michal Suchanek <hramr...@gmail.com> wrote: >>> On 14 June 2016 at 06:47, Julian Calaby <julian.cal...@gmail.com> wrote: >>>> Hi Michal, >>>> >>>> On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek <hramr...@gmail.com> >>>> wrote: >>>>> Hello, >>>>> >>>>> On 14 June 2016 at 01:43, Julian Calaby <julian.cal...@gmail.com> wrote: >>>>>> Hi Michal, >>>>>> >>>>>> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> >>>>>> wrote: >>>>>>> The drivers are very similar and share multiple flaws which needed >>>>>>> separate fixes for both drivers. >>>>>>> >>>>>>> Signed-off-by: Michal Suchanek <hramr...@gmail.com> >>>>>>> --- >>>>>>> drivers/spi/Kconfig | 8 +- >>>>>>> drivers/spi/Makefile| 1 - >>>>>>> drivers/spi/spi-sun4i.c | 156 +++-- >>>>>>> drivers/spi/spi-sun6i.c | 598 >>>>>>> >>>>>>> 4 files changed, 143 insertions(+), 620 deletions(-) >>>>>>> delete mode 100644 drivers/spi/spi-sun6i.c >>>>>>> >>>>>>> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c >>>>>>> index 0b8e6c6..c76f8e4 100644 >>>>>>> --- a/drivers/spi/spi-sun4i.c >>>>>>> +++ b/drivers/spi/spi-sun4i.c >>>>>>> @@ -279,9 +321,14 @@ static int sunxi_spi_transfer_one(struct >>>>>>> spi_master *master, >>>>>>> reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG); >>>>>>> >>>>>>> /* Reset FIFOs */ >>>>>>> - sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, >>>>>>> - reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) | >>>>>>> - sspi_bits(sspi, SUNXI_CTL_TF_RST)); >>>>>>> + if (sspi->type == SPI_SUN4I) >>>>>>> + sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, >>>>>>> + reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) >>>>>>> | >>>>>>> + sspi_bits(sspi, SUNXI_CTL_TF_RST)); >>>>>>> + else >>>>>>> + sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG, >>>>>>> + sspi_bits(sspi, SUNXI_CTL_RF_RST) | >>>>>>> + sspi_bits(sspi, SUNXI_CTL_TF_RST)); >>>>>> >>>>>> If we're already doing different stuff for each generation of the IP, >>>>>> why not just use the register offsets and bit definitions directly? >>>>> >>>>> Because having (*sspi->regmap)[SUNXI_FIFO_CTL_REG] all over the place >>>>> makes my eyes bleed and you cannot use the check that you are >>>>> accessing a register that actually exists. >>>> >>>> I mean removing SUNXI_CTL_RF_RST and SUNXI_CTL_TF_RST from all of the >>>> indirection you added and using them directly, i.e. >>>> >>>> #define SUN4I_TFR_CTL_RF_RST BIT(x) >>>> #define SUN4I_TFR_CTL_TF_RST BIT(x) >>>> #define SUN6I_FIFO_CTL_RF_RST BIT(x) >>>> #define SUN6I_FIFO_CTL_TF_RST BIT(x) >>>> >>>> then >>>> >>>> if (sspi->type == SPI_SUN4I) >>>> sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, reg | >>>> SUN4I_TFR_CTL_RF_RST | SUN4I_TFR_CTL_TF_RST); >>>> else >>>> sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG, reg | >>>> SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST); >>>> >>>> I.e. the bits that need setting are in different registers, so you >>>> have to have an if statement and separate calls. Therefore there's no >>>> real benefit from the indirection you've introduced here, unless >>>> you're expecting the SUN8I variant to use different bits in one of >>>> those two registers. >>>> >>> >>>
Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver
Hi Michal, On Tue, Jun 14, 2016 at 3:28 PM, Michal Suchanek <hramr...@gmail.com> wrote: > On 14 June 2016 at 06:47, Julian Calaby <julian.cal...@gmail.com> wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek <hramr...@gmail.com> wrote: >>> Hello, >>> >>> On 14 June 2016 at 01:43, Julian Calaby <julian.cal...@gmail.com> wrote: >>>> Hi Michal, >>>> >>>> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> >>>> wrote: >>>>> The drivers are very similar and share multiple flaws which needed >>>>> separate fixes for both drivers. >>>>> >>>>> Signed-off-by: Michal Suchanek <hramr...@gmail.com> >>>>> --- >>>>> drivers/spi/Kconfig | 8 +- >>>>> drivers/spi/Makefile| 1 - >>>>> drivers/spi/spi-sun4i.c | 156 +++-- >>>>> drivers/spi/spi-sun6i.c | 598 >>>>> >>>>> 4 files changed, 143 insertions(+), 620 deletions(-) >>>>> delete mode 100644 drivers/spi/spi-sun6i.c >>>>> >>>>> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c >>>>> index 0b8e6c6..c76f8e4 100644 >>>>> --- a/drivers/spi/spi-sun4i.c >>>>> +++ b/drivers/spi/spi-sun4i.c >>>>> @@ -279,9 +321,14 @@ static int sunxi_spi_transfer_one(struct spi_master >>>>> *master, >>>>> reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG); >>>>> >>>>> /* Reset FIFOs */ >>>>> - sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, >>>>> - reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) | >>>>> - sspi_bits(sspi, SUNXI_CTL_TF_RST)); >>>>> + if (sspi->type == SPI_SUN4I) >>>>> + sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, >>>>> + reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) | >>>>> + sspi_bits(sspi, SUNXI_CTL_TF_RST)); >>>>> + else >>>>> + sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG, >>>>> + sspi_bits(sspi, SUNXI_CTL_RF_RST) | >>>>> + sspi_bits(sspi, SUNXI_CTL_TF_RST)); >>>> >>>> If we're already doing different stuff for each generation of the IP, >>>> why not just use the register offsets and bit definitions directly? >>> >>> Because having (*sspi->regmap)[SUNXI_FIFO_CTL_REG] all over the place >>> makes my eyes bleed and you cannot use the check that you are >>> accessing a register that actually exists. >> >> I mean removing SUNXI_CTL_RF_RST and SUNXI_CTL_TF_RST from all of the >> indirection you added and using them directly, i.e. >> >> #define SUN4I_TFR_CTL_RF_RST BIT(x) >> #define SUN4I_TFR_CTL_TF_RST BIT(x) >> #define SUN6I_FIFO_CTL_RF_RST BIT(x) >> #define SUN6I_FIFO_CTL_TF_RST BIT(x) >> >> then >> >> if (sspi->type == SPI_SUN4I) >> sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, reg | >> SUN4I_TFR_CTL_RF_RST | SUN4I_TFR_CTL_TF_RST); >> else >> sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG, reg | >> SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST); >> >> I.e. the bits that need setting are in different registers, so you >> have to have an if statement and separate calls. Therefore there's no >> real benefit from the indirection you've introduced here, unless >> you're expecting the SUN8I variant to use different bits in one of >> those two registers. >> > > That looks nice for this particular case. There was another case I pointed out in this driver that could potentially benefit from this. > Still you will have to remember that these bits are specified directly > while other bits on the register are mapped which is not so nice. True. I'm not sure which path is best in this case. To my eye, your indirection scheme seems like the "heavy" solution, however I have no idea what form a "lighter" solution would take. Other drivers I've seen which have tackled similar problems have used a large struct to hold all the variant-specific stuff, whether that's function pointers, register offsets, constants, etc. (so this code could theoretically be re-written as sunxi_spi_write(sspi, sspi->fifo_reg, reg | sspi->fifo_reset_arg) or sspi->reset_fifo()) however the driver I saw doing this (rtl8xxxu) was handling much more significant differences between device variants than you are. 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.
Re: [linux-sunxi] [PATCH v3 11/13] dt: spi: sun4i: merge sun4i and sun6i binding doc
Hi Michal,
On Tue, Jun 14, 2016 at 2:40 PM, Michal Suchanek <hramr...@gmail.com> wrote:
> On 14 June 2016 at 01:45, Julian Calaby <julian.cal...@gmail.com> wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> wrote:
>>> Signed-off-by: Michal Suchanek <hramr...@gmail.com>
>>> ---
>>> .../devicetree/bindings/spi/spi-sun4i.txt | 21 ++-
>>> .../devicetree/bindings/spi/spi-sun6i.txt | 24
>>> --
>>> 2 files changed, 11 insertions(+), 34 deletions(-)
>>> delete mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt
>>> b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
>>> index de827f5..329e543 100644
>>> --- a/Documentation/devicetree/bindings/spi/spi-sun4i.txt
>>> +++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
>>> @@ -1,7 +1,8 @@
>>> -Allwinner A10 SPI controller
>>> +Allwinner A10/A31 SPI controller
>>>
>>> Required properties:
>>> -- compatible: Should be "allwinner,sun4-a10-spi".
>>> +- compatible: Should be one of "allwinner,sun4i-a10-spi" and
>>> + "allwinner,sun6i-a31-spi"
>>> - reg: Should contain register location and length.
>>> - interrupts: Should contain interrupt.
>>> - clocks: phandle to the clocks feeding the SPI controller. Two are
>>> @@ -9,16 +10,16 @@ Required properties:
>>>- "ahb": the gated AHB parent clock
>>>- "mod": the parent module clock
>>> - clock-names: Must contain the clock names described just above
>>> +- resets: (sun6i only) phandle to the reset controller asserting
>>> + this device in reset
>>>
>>> Example:
>>>
>>> -spi1: spi@01c06000 {
>>> - compatible = "allwinner,sun4i-a10-spi";
>>> - reg = <0x01c06000 0x1000>;
>>> - interrupts = <11>;
>>> - clocks = <_gates 21>, <_clk>;
>>> +spi1: spi@01c69000 {
>>> + compatible = "allwinner,sun6i-a31-spi";
>>> + reg = <0x01c69000 0x1000>;
>>> + interrupts = <0 66 4>;
>>> + clocks = <_gates 21>, <_clk>;
>>> clock-names = "ahb", "mod";
>>> - status = "disabled";
>>> - #address-cells = <1>;
>>> - #size-cells = <0>;
>>> + resets = <_rst 21>;
>>
>> Why not have an example of each type?
>
> How many binding docs have examples of all types?
I'm pretty sure that there's a few. This was only a suggestion, so if
it's not to your taste, ignore it.
> There are actual DTs using these so you can look at those as well.
>
> This driver covers 3 types of bindings which look different in the DT:
>
> sun4i IP with some Chinese interrupt controller, sun4i IP with GIC,
> and sun6i IP with GIC.
Fair point.
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.
Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver
Hi Michal, On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek <hramr...@gmail.com> wrote: > Hello, > > On 14 June 2016 at 01:43, Julian Calaby <julian.cal...@gmail.com> wrote: >> Hi Michal, >> >> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> wrote: >>> The drivers are very similar and share multiple flaws which needed >>> separate fixes for both drivers. >>> >>> Signed-off-by: Michal Suchanek <hramr...@gmail.com> >>> --- >>> drivers/spi/Kconfig | 8 +- >>> drivers/spi/Makefile| 1 - >>> drivers/spi/spi-sun4i.c | 156 +++-- >>> drivers/spi/spi-sun6i.c | 598 >>> >>> 4 files changed, 143 insertions(+), 620 deletions(-) >>> delete mode 100644 drivers/spi/spi-sun6i.c >>> >>> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c >>> index 0b8e6c6..c76f8e4 100644 >>> --- a/drivers/spi/spi-sun4i.c >>> +++ b/drivers/spi/spi-sun4i.c >>> @@ -279,9 +321,14 @@ static int sunxi_spi_transfer_one(struct spi_master >>> *master, >>> reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG); >>> >>> /* Reset FIFOs */ >>> - sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, >>> - reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) | >>> - sspi_bits(sspi, SUNXI_CTL_TF_RST)); >>> + if (sspi->type == SPI_SUN4I) >>> + sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, >>> + reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) | >>> + sspi_bits(sspi, SUNXI_CTL_TF_RST)); >>> + else >>> + sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG, >>> + sspi_bits(sspi, SUNXI_CTL_RF_RST) | >>> + sspi_bits(sspi, SUNXI_CTL_TF_RST)); >> >> If we're already doing different stuff for each generation of the IP, >> why not just use the register offsets and bit definitions directly? > > Because having (*sspi->regmap)[SUNXI_FIFO_CTL_REG] all over the place > makes my eyes bleed and you cannot use the check that you are > accessing a register that actually exists. I mean removing SUNXI_CTL_RF_RST and SUNXI_CTL_TF_RST from all of the indirection you added and using them directly, i.e. #define SUN4I_TFR_CTL_RF_RST BIT(x) #define SUN4I_TFR_CTL_TF_RST BIT(x) #define SUN6I_FIFO_CTL_RF_RST BIT(x) #define SUN6I_FIFO_CTL_TF_RST BIT(x) then if (sspi->type == SPI_SUN4I) sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, reg | SUN4I_TFR_CTL_RF_RST | SUN4I_TFR_CTL_TF_RST); else sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG, reg | SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST); I.e. the bits that need setting are in different registers, so you have to have an if statement and separate calls. Therefore there's no real benefit from the indirection you've introduced here, unless you're expecting the SUN8I variant to use different bits in one of those two registers. 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.
Re: [linux-sunxi] [PATCH v3 11/13] dt: spi: sun4i: merge sun4i and sun6i binding doc
Hi Michal,
On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> wrote:
> Signed-off-by: Michal Suchanek <hramr...@gmail.com>
> ---
> .../devicetree/bindings/spi/spi-sun4i.txt | 21 ++-
> .../devicetree/bindings/spi/spi-sun6i.txt | 24
> --
> 2 files changed, 11 insertions(+), 34 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt
> b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
> index de827f5..329e543 100644
> --- a/Documentation/devicetree/bindings/spi/spi-sun4i.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
> @@ -1,7 +1,8 @@
> -Allwinner A10 SPI controller
> +Allwinner A10/A31 SPI controller
>
> Required properties:
> -- compatible: Should be "allwinner,sun4-a10-spi".
> +- compatible: Should be one of "allwinner,sun4i-a10-spi" and
> + "allwinner,sun6i-a31-spi"
> - reg: Should contain register location and length.
> - interrupts: Should contain interrupt.
> - clocks: phandle to the clocks feeding the SPI controller. Two are
> @@ -9,16 +10,16 @@ Required properties:
>- "ahb": the gated AHB parent clock
>- "mod": the parent module clock
> - clock-names: Must contain the clock names described just above
> +- resets: (sun6i only) phandle to the reset controller asserting
> + this device in reset
>
> Example:
>
> -spi1: spi@01c06000 {
> - compatible = "allwinner,sun4i-a10-spi";
> - reg = <0x01c06000 0x1000>;
> - interrupts = <11>;
> - clocks = <_gates 21>, <_clk>;
> +spi1: spi@01c69000 {
> + compatible = "allwinner,sun6i-a31-spi";
> + reg = <0x01c69000 0x1000>;
> + interrupts = <0 66 4>;
> + clocks = <_gates 21>, <_clk>;
> clock-names = "ahb", "mod";
> - status = "disabled";
> - #address-cells = <1>;
> - #size-cells = <0>;
> + resets = <_rst 21>;
Why not have an example of each type?
> };
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.
Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver
Hi Michal,
On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> wrote:
> The drivers are very similar and share multiple flaws which needed
> separate fixes for both drivers.
>
> Signed-off-by: Michal Suchanek <hramr...@gmail.com>
> ---
> drivers/spi/Kconfig | 8 +-
> drivers/spi/Makefile| 1 -
> drivers/spi/spi-sun4i.c | 156 +++--
> drivers/spi/spi-sun6i.c | 598
>
> 4 files changed, 143 insertions(+), 620 deletions(-)
> delete mode 100644 drivers/spi/spi-sun6i.c
>
> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
> index 0b8e6c6..c76f8e4 100644
> --- a/drivers/spi/spi-sun4i.c
> +++ b/drivers/spi/spi-sun4i.c
> @@ -279,9 +321,14 @@ static int sunxi_spi_transfer_one(struct spi_master
> *master,
> reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG);
>
> /* Reset FIFOs */
> - sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG,
> - reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) |
> - sspi_bits(sspi, SUNXI_CTL_TF_RST));
> + if (sspi->type == SPI_SUN4I)
> + sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG,
> + reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) |
> + sspi_bits(sspi, SUNXI_CTL_TF_RST));
> + else
> + sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG,
> + sspi_bits(sspi, SUNXI_CTL_RF_RST) |
> + sspi_bits(sspi, SUNXI_CTL_TF_RST));
If we're already doing different stuff for each generation of the IP,
why not just use the register offsets and bit definitions directly?
>
> /*
> * Setup the transfer control register: Chip Select,
> @@ -427,7 +473,19 @@ static int sunxi_spi_runtime_resume(struct device *dev)
> goto err;
> }
>
> - sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG,
> + if (sspi->rstc) {
> + ret = reset_control_deassert(sspi->rstc);
> + if (ret) {
> + dev_err(dev, "Couldn't deassert the device from
> reset\n");
> + goto err2;
> + }
> + }
> +
> + if (sspi->type == SPI_SUN4I)
> + reg = SUNXI_TFR_CTL_REG;
> + else
> + reg = SUNXI_GBL_CTL_REG;
> + sunxi_spi_write(sspi, reg,
> sspi_bits(sspi, SUNXI_CTL_ENABLE) |
> sspi_bits(sspi, SUNXI_CTL_MASTER) |
> sspi_bits(sspi, SUNXI_CTL_TP));
Same here.
> @@ -491,10 +558,37 @@ static int sunxi_spi_probe(struct platform_device *pdev)
> }
>
> sspi->master = master;
> - sspi->fifo_depth = SUN4I_FIFO_DEPTH;
> - sspi->type = SPI_SUN4I;
> - sspi->regmap = _regmap;
> - sspi->bitmap = _bitmap;
> + if (of_device_is_compatible(pdev->dev.of_node, SUN4I_COMPATIBLE)) {
> + sspi->fifo_depth = SUN4I_FIFO_DEPTH;
> + sspi->type = SPI_SUN4I;
> + sspi->regmap = _regmap;
> + sspi->bitmap = _bitmap;
> + } else if (of_device_is_compatible(pdev->dev.of_node,
> + SUN6I_COMPATIBLE)) {
> + sspi->fifo_depth = SUN6I_FIFO_DEPTH;
> + sspi->type = SPI_SUN6I;
> + sspi->regmap = _regmap;
> + sspi->bitmap = _bitmap;
Can you store data in the match table instead of doing this?
> + } else {
> + const char *str = NULL;
> + int i = 1;
> +
> + of_property_read_string(pdev->dev.of_node, "compatible",
> );
> + dev_err(>dev, "Unknown device compatible %s", str);
> + /* is there no sane way to print a string array property ? */
> + if (of_property_count_strings(pdev->dev.of_node, "compatible")
> + > 1) {
> + while
> (!of_property_read_string_index(pdev->dev.of_node,
> + "compatible", i,
> + )) {
> + pr_err(", %s", str);
> + i++;
> + }
> + }
> + ret = -EINVAL;
> + goto err_free_master;
> + }
> +
> master->max_speed_hz = 100 * 1000 * 1000;
> master->min_speed_hz = 3 * 1000;
> master->set_cs = sunxi_spi_set_cs;
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.
Re: [linux-sunxi] [PATCH v3 07/13] spi: sunxi: rename constants to match between sun4i and sun6i
Hi Michal, On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> wrote: > SUNXI_CTL_ -> SUNXI_TFR_CTL_ > SUNXI_TFR_CTL_LMTF -> SUNXI_TFR_CTL_FBS I don't know these abbreviations, are they both referring to the same thing? > SUNXI_TFR_CTL_CS_ACTIVE_LOW -> SUNXI_TFR_CTL_SPOL It looks like you're making the constant name less descriptive here. Is the old version (CS_ACTIVE_LOW) incorrect? > and some SUNXI_???_CTL_ -> SUNXI_CTL_ > for constants migrated to different registers between sun4i and sun6i > > No functional change. > > Signed-off-by: Michal Suchanek <hramr...@gmail.com> > --- > drivers/spi/spi-sun4i.c | 68 > - > drivers/spi/spi-sun6i.c | 14 +- > 2 files changed, 41 insertions(+), 41 deletions(-) > > diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c > index 155d720..b7f8de1 100644 > --- a/drivers/spi/spi-sun4i.c > +++ b/drivers/spi/spi-sun4i.c > @@ -28,21 +28,21 @@ > > #define SUNXI_TXDATA_REG 0x04 > > -#define SUNXI_CTL_REG 0x08 > +#define SUNXI_TFR_CTL_REG 0x08 > #define SUNXI_CTL_ENABLE BIT(0) > #define SUNXI_CTL_MASTER BIT(1) > -#define SUNXI_CTL_CPHA BIT(2) > -#define SUNXI_CTL_CPOL BIT(3) > -#define SUNXI_CTL_CS_ACTIVE_LOWBIT(4) > -#define SUNXI_CTL_LMTF BIT(6) > +#define SUNXI_TFR_CTL_CPHA BIT(2) > +#define SUNXI_TFR_CTL_CPOL BIT(3) > +#define SUNXI_TFR_CTL_SPOL BIT(4) > +#define SUNXI_TFR_CTL_FBS BIT(6) > #define SUNXI_CTL_TF_RST BIT(8) > #define SUNXI_CTL_RF_RST BIT(9) > -#define SUNXI_CTL_XCH BIT(10) > -#define SUNXI_CTL_CS_MASK 0x3000 > -#define SUNXI_CTL_CS(cs) (((cs) << 12) & SUNXI_CTL_CS_MASK) > -#define SUNXI_CTL_DHB BIT(15) > -#define SUNXI_CTL_CS_MANUALBIT(16) > -#define SUNXI_CTL_CS_LEVEL BIT(17) > +#define SUNXI_TFR_CTL_XCH BIT(10) > +#define SUNXI_TFR_CTL_CS_MASK 0x3000 > +#define SUNXI_TFR_CTL_CS(cs) (((cs) << 12) & SUNXI_TFR_CTL_CS_MASK) > +#define SUNXI_TFR_CTL_DHB BIT(15) > +#define SUNXI_TFR_CTL_CS_MANUALBIT(16) > +#define SUNXI_TFR_CTL_CS_LEVEL BIT(17) > #define SUNXI_CTL_TP BIT(18) > > #define SUNXI_INT_CTL_REG 0x0c > diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c > index a27bf8f..f26b52a 100644 > --- a/drivers/spi/spi-sun6i.c > +++ b/drivers/spi/spi-sun6i.c > @@ -26,9 +26,9 @@ > #define SUNXI_FIFO_DEPTH 128 > > #define SUNXI_GBL_CTL_REG 0x04 > -#define SUNXI_GBL_CTL_BUS_ENABLE BIT(0) > -#define SUNXI_GBL_CTL_MASTER BIT(1) > -#define SUNXI_GBL_CTL_TP BIT(7) > +#define SUNXI_CTL_ENABLE BIT(0) > +#define SUNXI_CTL_MASTER BIT(1) > +#define SUNXI_CTL_TP BIT(7) If these are bit definitions for the GBL register, why throw that information away? > #define SUNXI_GBL_CTL_RST BIT(31) > > #define SUNXI_TFR_CTL_REG 0x08 > @@ -50,8 +50,8 @@ > #define SUNXI_INT_STA_REG 0x14 > > #define SUNXI_FIFO_CTL_REG 0x18 > -#define SUNXI_FIFO_CTL_RF_RST BIT(15) > -#define SUNXI_FIFO_CTL_TF_RST BIT(31) > +#define SUNXI_CTL_RF_RST BIT(15) > +#define SUNXI_CTL_TF_RST BIT(31) Same here with FIFO. > > #define SUNXI_FIFO_STA_REG 0x1c > #define SUNXI_FIFO_STA_RF_CNT_MASK 0x7f My gut feeling on this is that we have a lot of cases of a definition of a register offset, then definitions of the bits in that register with that register encoded into the constant's name. You appear to be throwing a lot of that information away which makes me worry. 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.
Re: [linux-sunxi] [PATCH] [V2] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board
Hi Luo yi,
On Thu, Jun 2, 2016 at 12:36 PM, <luoyi...@gmail.com> wrote:
> From: Luo Yi <luoyi...@gmail.com>
>
> Add support for the Bananapi M1 Plus A20 development board from
> sinovoip.com.cn . This board is nearly a clone of the Lemaker's
> Bananapro, but differ with the wlan chipset connection and i2s pinout.
> And I also enable the integrated audio codec on default.
No signed-off-by.
> ---
> arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 72
>
> 1 file changed, 72 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> new file mode 100644
> index 000..6fd55d7
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
> @@ -0,0 +1,72 @@
> +/*
> + * Copyright 2016 Luo Yi <luoyi...@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "sun7i-a20-bananapro.dts"
> +
> +/ {
> + model = "Banana Pi BPI-M1-Plus";
> + compatible = "sinovoip,bpi-m1-plus", "allwinner,sun7i-a20";
> +};
> +
> +
Extra line.
> + {
> + status = "okay";
> +};
Does anyone know if this should be enabled on the bananapro too?
> +
> + {
> + enable-sdio-wakeup;
> +
> + brcmf: bcrmf@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <>;
> + interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "host-wake";
> + };
> +
Extra line.
> +};
> +
> +_pins_a {
> +/* AP6210 requires pull-up */
Should this be indented the same as the following line?
> + allwinner,pull = ;
> +};
> +
Extra line.
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.
Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout
Hi Michal,
On Fri, May 27, 2016 at 3:05 PM, Michal Suchanek <hramr...@gmail.com> wrote:
> On 27 May 2016 at 04:05, Julian Calaby <julian.cal...@gmail.com> wrote:
>> Hi Michal,
>>
>> On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek <hramr...@gmail.com> wrote:
>>> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
>>> 1MHz SPI bus takes way longer than that. Calculate the timeout from the
>>> actual time the transfer is supposed to take and multiply by 2 for good
>>> measure.
>>>
>>> Signed-off-by: Michal Suchanek <hramr...@gmail.com>
>>> ---
>>>
>>> v2:
>>> - fix build error
>>> - use unsigned instead of int in max_t
>>> - use tfr->speed_hz instead of sspi->max_speed_hz
>>> ---
>>> drivers/spi/spi-sun4i.c | 11 ++-
>>> drivers/spi/spi-sun6i.c | 11 ++-
>>> 2 files changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
>>> index 1ddd9e2..fe63bbd 100644
>>> --- a/drivers/spi/spi-sun4i.c
>>> +++ b/drivers/spi/spi-sun4i.c
>>> @@ -173,6 +173,7 @@ static int sun4i_spi_transfer_one(struct spi_master
>>> *master,
>>> {
>>> struct sun4i_spi *sspi = spi_master_get_devdata(master);
>>> unsigned int mclk_rate, div, timeout;
>>> + unsigned int start, end, tx_time;
>>> unsigned int tx_len = 0;
>>> int ret = 0;
>>> u32 reg;
>>> @@ -279,9 +280,17 @@ static int sun4i_spi_transfer_one(struct spi_master
>>> *master,
>>> reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
>>> sun4i_spi_write(sspi, SUN4I_CTL_REG, reg | SUN4I_CTL_XCH);
>>>
>>> + tx_time = max_t(unsigned, tfr->len * 8 * 2 / (tfr->speed_hz / 1000),
>>
>> You should probably use "unsigned int" instead of just "unsigned" here.
>>
>>> + 100);
>
> Or just 100U constant and avoid max_t altogether.
>
>>> + start = jiffies;
>>> timeout = wait_for_completion_timeout(>done,
>>> - msecs_to_jiffies(1000));
>>> + msecs_to_jiffies(tx_time));
>>> + end = jiffies;
>>> if (!timeout) {
>>> + dev_warn(>dev,
>>> +"%s: timeout transferring %u bytes@%iHz for
>>> %i(%i)ms",
>>> +dev_name(>dev), tfr->len, tfr->speed_hz,
>>> +jiffies_to_msecs(end - start), tx_time);
>>
>> Should the debug changes be in a separate patch?
>
> Is this so big of a change that it needs to be split?
Some people get touchy about changes not being mentioned in the commit
log. Technically this is two changes: fixing the timeout and adding
the timeout debugging, however they're related, so maybe just mention
that you've added this debugging in the commit log.
>
>>
>>> ret = -ETIMEDOUT;
>>> goto out;
>>> }
>>> diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
>>> index 42e2c4b..8be5c5c 100644
>>> --- a/drivers/spi/spi-sun6i.c
>>> +++ b/drivers/spi/spi-sun6i.c
>>> @@ -162,6 +162,7 @@ static int sun6i_spi_transfer_one(struct spi_master
>>> *master,
>>> unsigned int mclk_rate, div, timeout;
>>> unsigned int tx_len = 0;
>>> int ret = 0;
>>> + unsigned int start, end, tx_time;
>>> u32 reg;
>>>
>>> /* We don't support transfer larger than the FIFO */
>>> @@ -269,9 +270,17 @@ static int sun6i_spi_transfer_one(struct spi_master
>>> *master,
>>> reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
>>> sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
>>>
>>> + tx_time = max_t(unsigned, tfr->len * 8 * 2 / (tfr->speed_hz / 1000),
>>
>> Ditto, "unsigned int" instead of "unsigned"?
>>
>>> + 100);
>>> + start = jiffies;
>>> timeout = wait_for_completion_timeout(>done,
>>> - msecs_to_jiffies(1000));
>>> + msecs_to_jiffies(tx_time));
>>> + end = jiffies;
>>> if (!timeout) {
>>> + dev_warn(>dev,
>>> +"%s: timeout transferring %u bytes@%iHz for
>>> %i(%i)ms",
>>> +dev_name(>dev), tfr->len, tfr->speed_hz,
>>> +jiffies_to_msecs(end - start), tx_time);
>>
>> Ditto, separate patch?
>>
>> Also, should the changes for the drivers be in two separate patches also?
>
> That's basically the same driver with different constants so I guess not.
Fair enough, I withdraw my comment then.
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.
Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout
Hi Michal,
On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek <hramr...@gmail.com> wrote:
> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
> 1MHz SPI bus takes way longer than that. Calculate the timeout from the
> actual time the transfer is supposed to take and multiply by 2 for good
> measure.
>
> Signed-off-by: Michal Suchanek <hramr...@gmail.com>
> ---
>
> v2:
> - fix build error
> - use unsigned instead of int in max_t
> - use tfr->speed_hz instead of sspi->max_speed_hz
> ---
> drivers/spi/spi-sun4i.c | 11 ++-
> drivers/spi/spi-sun6i.c | 11 ++-
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
> index 1ddd9e2..fe63bbd 100644
> --- a/drivers/spi/spi-sun4i.c
> +++ b/drivers/spi/spi-sun4i.c
> @@ -173,6 +173,7 @@ static int sun4i_spi_transfer_one(struct spi_master
> *master,
> {
> struct sun4i_spi *sspi = spi_master_get_devdata(master);
> unsigned int mclk_rate, div, timeout;
> + unsigned int start, end, tx_time;
> unsigned int tx_len = 0;
> int ret = 0;
> u32 reg;
> @@ -279,9 +280,17 @@ static int sun4i_spi_transfer_one(struct spi_master
> *master,
> reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
> sun4i_spi_write(sspi, SUN4I_CTL_REG, reg | SUN4I_CTL_XCH);
>
> + tx_time = max_t(unsigned, tfr->len * 8 * 2 / (tfr->speed_hz / 1000),
You should probably use "unsigned int" instead of just "unsigned" here.
> + 100);
> + start = jiffies;
> timeout = wait_for_completion_timeout(>done,
> - msecs_to_jiffies(1000));
> + msecs_to_jiffies(tx_time));
> + end = jiffies;
> if (!timeout) {
> + dev_warn(>dev,
> +"%s: timeout transferring %u bytes@%iHz for
> %i(%i)ms",
> +dev_name(>dev), tfr->len, tfr->speed_hz,
> +jiffies_to_msecs(end - start), tx_time);
Should the debug changes be in a separate patch?
> ret = -ETIMEDOUT;
> goto out;
> }
> diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
> index 42e2c4b..8be5c5c 100644
> --- a/drivers/spi/spi-sun6i.c
> +++ b/drivers/spi/spi-sun6i.c
> @@ -162,6 +162,7 @@ static int sun6i_spi_transfer_one(struct spi_master
> *master,
> unsigned int mclk_rate, div, timeout;
> unsigned int tx_len = 0;
> int ret = 0;
> + unsigned int start, end, tx_time;
> u32 reg;
>
> /* We don't support transfer larger than the FIFO */
> @@ -269,9 +270,17 @@ static int sun6i_spi_transfer_one(struct spi_master
> *master,
> reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
> sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
>
> + tx_time = max_t(unsigned, tfr->len * 8 * 2 / (tfr->speed_hz / 1000),
Ditto, "unsigned int" instead of "unsigned"?
> + 100);
> + start = jiffies;
> timeout = wait_for_completion_timeout(>done,
> - msecs_to_jiffies(1000));
> + msecs_to_jiffies(tx_time));
> + end = jiffies;
> if (!timeout) {
> + dev_warn(>dev,
> + "%s: timeout transferring %u bytes@%iHz for
> %i(%i)ms",
> +dev_name(>dev), tfr->len, tfr->speed_hz,
> +jiffies_to_msecs(end - start), tx_time);
Ditto, separate patch?
Also, should the changes for the drivers be in two separate patches also?
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.
Re: [linux-sunxi] Re: PATH[1/3] ARM: axp20x_usb_power.c add device tree configuration options for REG 30H: VBUS-IPSOUT
Hi Ene,
On Wed, May 18, 2016 at 3:50 AM, Ene Alexandru <ene.alexan...@gmail.com> wrote:
> the documentation is updated to describe how to convert actual values to the
> provided parameters
>
> ---
> diff -uprN -X linux-sunxi-original/Documentation/dontdiff
> linux-sunxi-original/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
> linux-sunxi/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
> ---
> linux-sunxi-original/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
> 2016-05-09 16:48:46.0 +0200
> +++
> linux-sunxi/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
> 2016-05-11 13:05:58.995873267 +0200
> @@ -5,6 +5,26 @@ Required Properties:
> This node is a subnode of the axp20x PMIC.
> +The following 3 parameters are configurable from the device-tree:
> + - vhold-enable
> + - bit 6 of register REG 30H: VBUS-IPSOUT Power Path
> Management
I don't think it's necessary to go into this much detail here.
> + - available values are:
> + - 0x00 : VBUS VHOLD voltage limiting
> control disabled
> + - 0x01 : VBUS VHOLD voltage limiting
> control enabled
If these are the only options available, why not make this property a boolean?
> + - vhold-set
> + - bits <5-3> of register REG 30H: VBUS-IPSOUT Power
> Path Management
> + - available values are from 0x00 to 0x07
> + - VHOLD = [400 + ( vhold-set & 0x07 ) * 10]
> in uV
What does this actually do? Is this the lower limit on the voltage? Is
this the voltage it'll try to maintain?
> + - ibus-limit
> + - bits <1-0> of register REG 30H: VBUS-IPSOUT Power
> Path Management
> + - available values are :
> + - 0x00 : 90uA
> + - 0x01 : 50uA
> + - 0x02 : 10uA
> + - 0x03 : unlimited
Again, what does this actually do? It looks like the current limit?
> +
> +
Extra blank line.
> Example:
> axp209: pmic@34 {
> @@ -30,5 +50,8 @@ axp209: pmic@34 {
> usb-power-supply: usb-power-supply {
>compatible = "x-powers,axp202-usb-power-supply";
> + vhold-enable = <0x01>;
> + vhold-set = <0x04>;
> + ibus-limit = <0x01>;
>};
> };
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.
Re: [linux-sunxi] Re: PATH[1/3] ARM: axp20x_usb_power.c add device tree configuration options for REG 30H: VBUS-IPSOUT
+#ifdef DEBUG
> + dev_info(>dev, "set ibus-limit property to
> %02X",
> + ((*prop)>>24));
> +#endif
Ditto.
> + ret = regmap_update_bits(power->regmap,
> AXP20X_VBUS_IPSOUT_MGMT,
> +
> AXP20X_VBUS_IPSOUT_MGMT_IBUS_MASK,
> + ((*prop)>>24));
> + if (ret)
> + return ret;
> + } else {
> +#ifdef DEBUG
> + dev_info(>dev, "no ibus-limit property found");
> +#endif
Ditto.
> + }
> +
> + return 0;
> +}
> +
> static int axp20x_usb_power_probe(struct platform_device *pdev)
> {
>struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> @@ -172,6 +272,7 @@ static int axp20x_usb_power_probe(struct
>static const char * const irq_names[] = { "VBUS_PLUGIN",
>"VBUS_REMOVAL", "VBUS_VALID", "VBUS_NOT_VALID" };
>int i, irq, ret;
> + struct device_node *node;
> if (!of_device_is_available(pdev->dev.of_node))
>return -ENODEV;
> @@ -208,6 +309,11 @@ static int axp20x_usb_power_probe(struct
>if (IS_ERR(power->supply))
>return PTR_ERR(power->supply);
> +
> + /* read DT configurations parameters, if available */
> + for_each_compatible_node(node, NULL,
> "x-powers,axp202-usb-power-supply")
> + axp20x_usb_power_read_params(node, power,
> pdev);
> +
>/* Request irqs after registering, as irqs may trigger
> immediately */
>for (i = 0; i < ARRAY_SIZE(irq_names); i++) {
>irq = platform_get_irq_byname(pdev, irq_names[i]);
> ---
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.
Re: Re: Re: [linux-sunxi] how to build boot loader for V3s via git repository
Hi, On Thu, May 12, 2016 at 1:31 AM, astankvai <astank...@digitalhomeland.cn> wrote: > Hello Calaby, > i meet an problem > [1.775453] init: do_mount errno=22 > the full log as attached. > Can you help to check where i should locate the issue? Not really. It looks like your init cannot find a filesystem to mount. I don't recognise the messages from init or the directories emitted so I can't help. 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.
Re: [linux-sunxi] [PATCH 2/2] ARM: dtsi: sun7i: Enable sun4i_can on Olinuxino-a20-Lime2
Hi Johannes,
On Tue, Apr 19, 2016 at 5:12 AM, Johannes Kuhn <gruemelmons...@gmail.com> wrote:
> Add can0 blocks for sun4i_can support to the Olinuxino-a20-Lime2 dts
>
> Signed-off-by: Johannes Kuhn <gruemelmonster+pa...@gmail.com>
> ---
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> index d5c796c..d539bad 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> @@ -278,3 +278,10 @@
> usb2_vbus-supply = <_usb2_vbus>;
> status = "okay";
> };
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + status = "okay";
> +};
> +
I believe that the entries in these files should be sorted
alphabetically. You've also added an extra line after the block.
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.
Re: [linux-sunxi] [PATCH 1/2] ARM: dtsi: sun7i: Enable sun4i_can on A20
Hi Johannes,
On Tue, Apr 19, 2016 at 5:12 AM, Johannes Kuhn <gruemelmons...@gmail.com> wrote:
> Add can0 blocks for sun4i_can support to the A20 dtsi
>
> Signed-off-by: Johannes Kuhn <gruemelmonster+pa...@gmail.com>
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index bf5d056..d199f34 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -56,6 +56,7 @@
>
> aliases {
> ethernet0 =
> + can0 =
> };
>
> chosen {
> @@ -1212,6 +1213,14 @@
> allwinner,drive = ;
> allwinner,pull = ;
> };
> +
> + can0_pins_a: can0@0 {
> + allwinner,pins = "PH20","PH21";
> + allwinner,function = "can";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
Extra line.
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.
Re: Re: [linux-sunxi] how to build boot loader for V3s via git repository
Hi, On Mon, Apr 11, 2016 at 11:28 AM, astankvai <astank...@digitalhomeland.cn> wrote: > Dear Calaby, > Many thanks. > I wonder to know where i can disscuss this kind of topic? > It's better to advise me a bbs where most of the people develop project with > Allwinner chips. If you're interested in adding support yourself, this is the place to discuss that. If you want something out-of-the-box right now then you need to speak either to Allwinner themselves or the vendor of your device. Thanks, Julian Calaby > thanks. > > > astankvai > 2016-04-11 > ________ > 发件人： Julian Calaby > 发送时间： 2016-04-10 21:19:17 > 收件人： astank...@digitalhomeland.cn > 抄送： linux-sunxi > 主题： Re: [linux-sunxi] how to build boot loader for V3s via git repository > > Hi, > > On Fri, Apr 8, 2016 at 7:56 PM, astankvai > <astank...@digitalhomeland.cn > wrote: >> Hello, >> I checked out the repository from >> >> git clone git://github.com/linux-sunxi/sunxi-boards.git >> >> But i didn't find chip list for V3/V3s and so on. what i >> should do for the >> bootloader building? > > As far as I know, there is absolutely no support for the V3 / > V3s in > mainline u-boot and linux. I don't believe that anyone here (other > than you) has hardware with one and is working on support for > them. > > (Also, that's not the repository with the bootloader config, that's > a > repository for .fex files from devices people have.) > > Thanks, > > -- > Julian Calaby > > Email: julian.cal...@gmail.com > Profile: http://www.google.com/profiles/julian.calaby/ > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2016.0.7497 / Virus Database: 4545/12007 - Release Date: > 04/10/16 > -- 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.
Re: [linux-sunxi] [PATCH v3 02/13] clk: sunxi: add ahb1 clock for A83T
n6i_ahb1_clk_setup);
>
> +static void __init sun8i_a83t_ahb1_clk_setup(struct device_node *node)
> +{
> + sunxi_factors_clk_setup(node, _a83t_ahb1_data);
> +}
> +CLK_OF_DECLARE(sun8i_a83t_ahb1, "allwinner,sun8i-a83t-ahb1-clk",
> + sun8i_a83t_ahb1_clk_setup);
> +
> static void __init sun4i_apb1_clk_setup(struct device_node *node)
> {
> sunxi_factors_clk_setup(node, _apb1_data);
> --
> 1.9.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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.
Re: [linux-sunxi] Re: [PATCH v3] Fix sun7i pin assignment for IRQ's
Hi Henry, On Mon, Feb 22, 2016 at 6:27 AM, Henry Paulissen <he...@nitronetworks.nl> wrote: > > Op zondag 21 februari 2016 18:18:37 UTC+1 schreef Maxime Ripard: >> >> >> Your commit log is going to need some work. Which bugs? What tests did >> you make? Why are you making these changes while the datasheet says >> otherwise? > > > Its a fix for a not yet existing bug. I was fiddling around with IRQ's and > couldn't get them to work. > I took a dumpster dive into it and found a shitload of contradicting manuals > and datasheets. > > > Take for example the A20 user manual: > http://dl.linux-sunxi.org/A20/A20%20user%20manual%20v1.3%2020141010.pdf > > (pin PI14) > Page 237: EINT26 is on mux *5* in the pin overview. > Page 288: EINT26 is on mux *6* in the registers. > > Page 233: EINT12 is on pin PC19 mux6 in the pin overview. > Page 236: EINT12 is on pin PH12 mux6 in the pin overview. > Page 253: EINT12 is *not* on pin PC19 on the registers. > Page 281: EINT12 is on pin PH12 mux6 in the registers. > > So manual may say otherwise, but I hope I have proven that the manual isn't > to be trusted. > > My patch is based onto testing from both me and Andre (apritzel). > He with a Banana PI M1 and me with a Cubietruck (both A20 soc). > > We did a basic test by connecting a pulsing signal to a port and configure > kernel to use irq. > > e.g. > echo pin# > /sys/class/gpio/export > echo in > /sys/class/gpio/gpio#/direction > echo rising > /sys/class/gpio/gpio#/edge > > and check on /proc/interrupts to see if a irq was attached and if it was > receiving. > > Im not sure what andre his pulse source was, but mine was a 1pps coming from > a gps. > > >> >> Have you tried to compile it? >> > > Yes, otherwise we could have never confirmed that the irq's where on mux6 > for the PI ports. I think Maxime is referring to the fact that your patch removes two closing parenthesis when one would expect that you'd only remove one. You have compiled the kernel with this patch applied and no other modifications, right? 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.
Re: [linux-sunxi] Re: [PATCH 11/11] arm64: dts: add Pine64 support
General Public License for more details.
>>> + *
>>> + * Or, alternatively,
>>> + *
>>> + * b) Permission is hereby granted, free of charge, to any person
>>> + * obtaining a copy of this software and associated documentation
>>> + * files (the "Software"), to deal in the Software without
>>> + * restriction, including without limitation the rights to use,
>>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>>> + * sell copies of the Software, and to permit persons to whom the
>>> + * Software is furnished to do so, subject to the following
>>> + * conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be
>>> + * included in all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + * OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "pine64_common.dtsi"
>>> +
>>> +/ {
>>> +model = "Pine64";
>>> +compatible = "pine64,pine64", "allwinner,a64", "allwinner,sunxi";
>>> +
>>> +chosen {
>>> +stdout-path = "serial0:115200n8";
>>> +};
>>> +
>>> +memory {
>>> +reg = <0x4000 0x2000>;
>>> +};
>>> +};
>>> diff --git a/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>>> b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>>> new file mode 100644
>>> index 000..d968d76
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>>> @@ -0,0 +1,76 @@
>>> +/*
>>> + * Copyright (c) 2016 ARM Ltd.
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + * a) This library 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 library 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.
>>> + *
>>> + * Or, alternatively,
>>> + *
>>> + * b) Permission is hereby granted, free of charge, to any person
>>> + * obtaining a copy of this software and associated documentation
>>> + * files (the "Software"), to deal in the Software without
>>> + * restriction, including without limitation the rights to use,
>>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>>> + * sell copies of the Software, and to permit persons to whom the
>>> + * Software is furnished to do so, subject to the following
>>> + * conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be
>>> + * included in all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + * OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +#include "a64.dtsi"
>>> +
>>> + {
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins>, <_default_cd_pin>;
>>> +vmmc-supply = <_vcc3v3>;
>>> +cd-gpios = < 5 6 0>;
>>> +cd-inverted;
>>> +status = "okay";
>>> +};
>>> +
>>> + {
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins_a>;
>>> +status = "okay";
>>> +};
>>> +
>>> + {
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins>;
>>> +status = "okay";
>>> +};
>>> +
>>> + {
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins_a>;
>>> +status = "okay";
>>> +};
>>> +
>>> + {
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins>;
>>> +status = "okay";
>>> +};
>>
>> Our policy for boards with "open" pin headers the user can plug
>> anything he wants is that unless the pin is explicitly dedicated to
>> that usage, we simply leave them aside so that we don't enforce
>> anything.
>
> Makes sense, I just wonder what a user is expected to do if she wants to
> use the serial ports?
> Hack the DT?
> Use U-Boot to create those nodes on the fly?
> Use overlays?
> Directly setup serial ports from userland? (thinking of this bloody
> mechanism x86 (used to?) have)
I believe that device tree overlays are the generally recommended method.
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.
Re: [linux-sunxi] [PATCH v2 4/5] ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi
Hi Krzysztof, On Wed, Feb 3, 2016 at 8:21 AM, Krzysztof Adamski <k...@japko.eu> wrote: > Add the corresponding device node for R_PIO on H3 to the dtsi. Support > for the controller was added in earlier commit. > > Signed-off-by: Krzysztof Adamski <k...@japko.eu> > --- > .../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + > arch/arm/boot/dts/sun8i-h3.dtsi | 12 > > 2 files changed, 13 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > index 9213b27..3e56b16 100644 > --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > @@ -21,6 +21,7 @@ Required properties: >"allwinner,sun9i-a80-r-pinctrl" >"allwinner,sun8i-a83t-pinctrl" >"allwinner,sun8i-h3-pinctrl" > + "allwinner,sun8i-h3-r-pinctrl" Shouldn't this change go in the patch that introduces the driver for this pinctl? 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.
Re: [linux-sunxi] [PATCH 01/11] MAINTAINERS: Add entry for X-Powers AXP family PMIC drivers
Hi Chen-Yu, On Tue, Feb 2, 2016 at 9:27 PM, Chen-Yu Tsai <w...@csie.org> wrote: > Add an entry for X-Powers AXP family PMIC drivers and list myself > as maintainer. > > Cc: Carlo Caione <ca...@caione.org> > Cc: Maxime Ripard <maxime.rip...@free-electrons.com> > Cc: Ramakrishna Pallala <ramakrishna.pall...@intel.com> > Cc: Todd Brandt <todd.e.bra...@linux.intel.com> > Cc: Jacob Pan <jacob.jun@linux.intel.com> > Signed-off-by: Chen-Yu Tsai <w...@csie.org> > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f678c37107f5..7ea4e54f566a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11941,6 +11941,12 @@ F: include/linux/workqueue.h > F: kernel/workqueue.c > F: Documentation/workqueue.txt > > +X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS > +M: Chen-Yu Tsai <w...@csie.org> > +L: linux-ker...@vger.kernel.org > +S: Maintained > +N: axp[128] Should you list the files maintained and this list also? > + > X.25 NETWORK LAYER > M: Andrew Hendry <andrew.hen...@gmail.com> > L: linux-...@vger.kernel.org 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.
Re: [linux-sunxi] [PATCH 01/11] MAINTAINERS: Add entry for X-Powers AXP family PMIC drivers
Hi Joe, On Wed, Feb 3, 2016 at 12:28 PM, Joe Perches <j...@perches.com> wrote: > On Wed, 2016-02-03 at 11:19 +1100, Julian Calaby wrote: >> On Tue, Feb 2, 2016 at 9:27 PM, Chen-Yu Tsai <w...@csie.org> wrote: >> > Add an entry for X-Powers AXP family PMIC drivers and list myself >> > as maintainer. > [] >> > diff --git a/MAINTAINERS b/MAINTAINERS > [] >> > @@ -11941,6 +11941,12 @@ F: include/linux/workqueue.h >> > F: kernel/workqueue.c >> > F: Documentation/workqueue.txt >> > >> > +X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS >> > +M: Chen-Yu Tsai <w...@csie.org> >> > +L: linux-ker...@vger.kernel.org >> > +S: Maintained >> > +N: axp[128] >> >> Should you list the files maintained and this list also? > > This "N:" pattern is kind of a wildcard. > > The difference between F: and N: is that git history > is also used by default for files that match. > > There are no files in -next today that match "*axp8*" > Dunno if this patchset added any. > > This matches: > > $ git ls-files | grep "axp[128]" > Documentation/devicetree/bindings/mfd/axp20x.txt > Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt > arch/arm/boot/dts/axp152.dtsi > arch/arm/boot/dts/axp209.dtsi > arch/arm/boot/dts/axp22x.dtsi > drivers/extcon/extcon-axp288.c > drivers/iio/adc/axp288_adc.c > drivers/input/misc/axp20x-pek.c > drivers/mfd/axp20x.c > drivers/power/axp20x_usb_power.c > drivers/power/axp288_charger.c > drivers/power/axp288_fuel_gauge.c > drivers/regulator/axp20x-regulator.c > include/linux/mfd/axp20x.h > > Are all these files appropriate? > I didn't know about the "N:" tag, and consequently I retract my comment. 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.
Re: [linux-sunxi] reason for Allwinner SoC specific pinctrl drivers?
Hi Andre,
On Mon, Jan 4, 2016 at 10:02 PM, Andre Przywara <andre.przyw...@arm.com> wrote:
> Hi,
>
> while looking at the Allwinner A64 SoC support, I was wondering why we
> would actually need a pinctrl driver (file) for each and every Allwinner
> SoC that we support.
> Looking at both the A20 and the A64 doc I don't see any differences in
> the port controller implementation apart from the actual
> muxval <-> subsystem assignment, which is just data, right?
> Comparing the code files in drivers/pinctrl/sunxi seems to support this,
> as those drivers only consist of the table and some boilerplate code.
>
> Now I was wondering whether we could get away with one generic Allwinner
> pinctrl driver and put the SoC specific pin assignments in DT instead.
> It looks like adding an "allwinner,muxval" property in addition to the
> existing "allwinner,function" in the SoC's .dtsi would give us all the
> information we need. This could look like:
>
> uart0_pins_a: uart0@0 {
> allwinner,pins = "PB22", "PB23";
> + allwinner,muxval = <0x020x02>;
> allwinner,function = "uart0";
> allwinner,drive = ;
> allwinner,pull = ;
> };
>
> Would it make sense that I sit down and prototype such a driver?
>
> We should keep compatibility with older DTs by keeping the existing
> drivers in (or maybe emulating the current behaviour by providing just
> those tables as a fallback) , but newer SoCs (like the A64?) would not
> need a SoC specific driver, but just go with that generic driver and
> appropriate DT properties.
>
> I appreciate any comments on this, especially if I missed something
> which would render this approach impossible or tedious.
I think that, as Michal said, merging the drivers might be possible,
however there's another three functions the drivers serve:
1. they're good documentation of how it's all configured. I'm not sure
your device tree based approach will be as user friendly in this
regard.
2. they list stuff we don't have a driver / hardware for yet
3. the policy on device-tree is to only include stuff we know is
working, which means we have a driver and hardware for that particular
thing. Device tree files for boards or SoCs have been rejected because
they list stuff that isn't used yet.
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.
Re: [linux-sunxi] Pine A64 Kickstarter Campaign Started
Hi, On Thu, Dec 10, 2015 at 11:11 AM, KH Goh <khgo...@gmail.com> wrote: > Hi, > Pine A64 Kickstarter Campaign Started 12 hour ago (on 9/Dec/2019 7.00am New > York Time), and at the moment total Backer is already more then 3500. > Below is the kickstarter page, > https://www.kickstarter.com/projects/pine64/pine-a64-first-15-64-bit-single-board-super-comput > > We also put up a wiki page > http://wiki.pine64.org/ A minor note on the details in your wiki: You might want to add dimensions to locate the external ports, SD/TD card and the Euler, Pi-2, camera and DSI ports. This will help people making cases for your board. 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.
Re: [linux-sunxi][PATCH 2/2] ARM: dts: sun4i: Add rikomagic mk802+ board
Hi Marcus,
On Wed, Dec 9, 2015 at 5:48 AM, <codekip...@gmail.com> wrote:
> From: Marcus Cooper <codekip...@gmail.com>
>
> The Rikomagic mk802+ is an Allwinner A10 based hdmi tv-stick, it features
> 1G RAM, 4G nand, a mini-hdmi female connector, USB-A receptacle, mini-usb
> receptacle (OTG), USB-wifi and an internal microphone. Like the original
> mk802, it does not use any pmic.
>
> Signed-off-by: Marcus Cooper <codekip...@gmail.com>
> ---
> arch/arm/boot/dts/Makefile| 1 +
> arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts | 50
> +++
> 2 files changed, 51 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ee8a1dc..f1cb0f8 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -600,6 +600,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-marsboard.dtb \
> sun4i-a10-mini-xplus.dtb \
> sun4i-a10-mk802.dtb \
> + sun4i-a10-mk802-1gb.dtb \
> sun4i-a10-mk802ii.dtb \
> sun4i-a10-olinuxino-lime.dtb \
> sun4i-a10-pcduino.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts
> b/arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts
> new file mode 100644
> index 000..eb77633
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-mk802-1gb.dts
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright 2015 Marcus Cooper <codekip...@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun4i-a10-mk802.dtsi"
> +
> +/ {
> + model = "Rikomagic MK802+";
> + compatible = "rikomagic,mk802-1gb", "allwinner,sun4i-a10";
> +
> +};
Are there any differences between the Rikomagic and the generic MK802?
You could just add another compatible to the original MK802 dts if there aren't.
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.
Re: [linux-sunxi] [PATCH 21/23] staging: mt29f_spinand: switch to mtd_ooblayout_ops
Hi Boris,
On Tue, Dec 8, 2015 at 9:26 AM, Boris Brezillon
<boris.brezil...@free-electrons.com> wrote:
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---
> drivers/staging/mt29f_spinand/mt29f_spinand.c | 44
> ---
> 1 file changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c
> b/drivers/staging/mt29f_spinand/mt29f_spinand.c
> index cb9d5ab..967d50a 100644
> --- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
> +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
> @@ -42,23 +42,29 @@ static inline struct spinand_state *mtd_to_state(struct
> mtd_info *mtd)
> static int enable_hw_ecc;
> static int enable_read_hw_ecc;
>
> -static struct nand_ecclayout spinand_oob_64 = {
> - .eccbytes = 24,
> - .eccpos = {
> - 1, 2, 3, 4, 5, 6,
> - 17, 18, 19, 20, 21, 22,
> - 33, 34, 35, 36, 37, 38,
> - 49, 50, 51, 52, 53, 54, },
> - .oobfree = {
> - {.offset = 8,
> - .length = 8},
> - {.offset = 24,
> - .length = 8},
> - {.offset = 40,
> - .length = 8},
> - {.offset = 56,
> - .length = 8},
> - }
> +static int spinand_oob_64_eccpos(struct mtd_info *mtd, int eccbyte)
> +{
> + if (eccbyte > 23)
> + return -ERANGE;
> +
> + return ((eccbyte / 6) * 16) + 1;
Are you sure this is correct? My reading of this is that we'd get 1
for eccbytes 0 through 5.
Would
((eccbyte / 6) * 16) + (eccbyte % 6) + 1
be more correct?
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.
Re: [linux-sunxi] [PATCH v5] sun4i-codec: add inputs
Hi Danny, You commit message needs some work. Firstly the title should be a little more descriptive, maybe something like sun4i-codec: Add FM, Line and Mic inputs On Tue, Dec 8, 2015 at 2:48 PM, Danny Milosavljevic <dan...@scratchpost.org> wrote: > Hi, > > this is the fifth version of the patch that adds inputs to sun4i-codec. > (Previous versions have been on the linux-sunxi mailing list only, > but this one went to the maintainers as well, > Message-Id: 20151208042013.11d31f09 () dayas) The salutation and info about previous versions being sunxi mailing list only should go beneath the three dashes. > The inputs added are: > - FM-In Left and Right > - Line-In Left and Right > - Mic1-In > - Mic2-In This needs to be reformatted to better describe what's happening in tht > Changes compared to v4 are: > - Mic preamplifier controls have more common names now. > - Mic preamplifier scale has a 0 dB entry as well now, as documented in the > A20 user manual. > - Mic preamplifier has special cases for A20 and A10 now. > - Gain controls have "Gain" in the name now. > > I successfully tested it on an A20 board using alsamixer, headphones, a radio > and > my ears. > Note that because of missing capturing support I tested only the mixing, > for Mic, Line, and FM. > > The patches are on top of > , > branch "sunxi/for-next". > > Regards, >Danny > > Danny (1): > b/sound/soc/sunxi/sun4i-codec.c | 153 > +++- > 1 file changed, 150 insertions(+), 3 deletions(-) The changelog, testing notes, source info and diffstat should also be below the three dashes. > Signed-off-by: Danny Milosavljevic <danny...@scratchpost.org> > --- So reformatting it, you'd get something like this: -->8-- Subject: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs Add inputs to sun4i-codec: - FM-in Left and Right - Line-in Left and Right - Mic1-in - Mic2-in Signed-off-by: Danny ... --- Hi, this is the fifth version of the patch that adds inputs to sun4i-codec. (Previous versions have been on the linux-sunxi mailing list only, but this one went to the maintainers as well, Message-Id: 20151208042013.11d31f09 () dayas) Changes compared to v4 are: - Mic preamplifier controls have more common names now. - Mic preamplifier scale has a 0 dB entry as well now, as documented in the A20 user manual. - Mic preamplifier has special cases for A20 and A10 now. - Gain controls have "Gain" in the name now. I successfully tested it on an A20 board using alsamixer, headphones, a radio and my ears. Note that because of missing capturing support I tested only the mixing, for Mic, Line, and FM. The patches are on top of , branch "sunxi/for-next". Regards, Danny Danny (1): b/sound/soc/sunxi/sun4i-codec.c | 153 +++- 1 file changed, 150 insertions(+), 3 deletions(-) -->8-- 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.
Re: [linux-sunxi] [PATCH 1/2] sunxi: twi: enable clocks on sun7i
Hi Oliver, On Fri, Dec 4, 2015 at 9:57 AM, Julian Calaby <julian.cal...@gmail.com> wrote: > Hi Oliver, > > On Fri, Dec 4, 2015 at 3:49 AM, Olliver Schinagl <oli...@schinagl.nl> wrote: >> From: Olliver Schinagl <o.schin...@ultimaker.com> >> >> Commit 6c739c5d added code to enable i2c bus 4 and 5 on the sun7i SoC >> but forgot to enable the clocks for these 2 i2c busses. >> >> This patch enables the clocks for i2c bus 4 and 5 on sun7i. >> >> Signed-off-by: Olliver Schinagl <o.schin...@ultimaker.com> >> --- >> arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c >> b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c >> index 7c8eff9..ed910b1 100644 >> --- a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c >> +++ b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c >> @@ -67,7 +67,11 @@ int clock_twi_onoff(int port, int state) >> struct sunxi_ccm_reg *const ccm = >> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; >> >> +#ifdef CONFIG_MACH_SUN7I >> + if (port > 4) >> +#else >> if (port > 2) >> +#endif > > Should the number here be a #define somewhere, or even a parameter for > each version of this clock? Wait, this is a u-boot patch, right? If so, ignore this and sorry for the noise. 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.
Re: [linux-sunxi] [PATCH 1/2] sunxi: twi: enable clocks on sun7i
Hi Oliver, On Fri, Dec 4, 2015 at 3:49 AM, Olliver Schinagl <oli...@schinagl.nl> wrote: > From: Olliver Schinagl <o.schin...@ultimaker.com> > > Commit 6c739c5d added code to enable i2c bus 4 and 5 on the sun7i SoC > but forgot to enable the clocks for these 2 i2c busses. > > This patch enables the clocks for i2c bus 4 and 5 on sun7i. > > Signed-off-by: Olliver Schinagl <o.schin...@ultimaker.com> > --- > arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c > b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c > index 7c8eff9..ed910b1 100644 > --- a/arch/arm/cpu/armv7/sunxi/clock_sun4i.c > +++ b/arch/arm/cpu/armv7/sunxi/clock_sun4i.c > @@ -67,7 +67,11 @@ int clock_twi_onoff(int port, int state) > struct sunxi_ccm_reg *const ccm = > (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; > > +#ifdef CONFIG_MACH_SUN7I > + if (port > 4) > +#else > if (port > 2) > +#endif Should the number here be a #define somewhere, or even a parameter for each version of this clock? 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.
Re: [linux-sunxi] [PATCH] spi: dts: sun4i: Add support for inter-word wait cycles using the SPI Wait Clock Register
Hi Marcus, On Fri, Nov 20, 2015 at 7:45 PM, Marcus Weseloh <mweselo...@gmail.com> wrote: > Hi Julian, > > 2015-11-19 23:59 GMT+01:00 Julian Calaby <julian.cal...@gmail.com>: >> Should you possibly hide the 3 clock periods from the user? >> >> I.e. they set whatever they want for the wdelay, we set it to the >> closest number we can that's greater or equal to what they ask for. > > That's a good idea and much better than having to remember to subtract > 3 cycles from the desired wait time! > > But it would mean that this magic number becomes part of the driver > code. I have found no official documentation that mentions those > additional cycles. While I have checked many different transmission > speeds using both CDR1 and CDR2 divider configurations, there is still > the possibility that the behaviour changes with weird SPI module > configurations... And I've only tested it on A20 hardware. So it would > be great if somebody else with access to A10 hardware and an > oscilloscope could check if we have a consistent 3 cycle overhead. Having magic numbers is kind-of a drivers' job. (and the wdelay should arguably be a core-spi thing, not a sunxi thing, but that's a separate discussion) If it is different for other SoCs, then you might have to move that constant somewhere else and introduce new compatible strings for them. 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.
Re: [linux-sunxi] [PATCH] spi: dts: sun4i: Add support for inter-word wait cycles using the SPI Wait Clock Register
Hi Marcus, On Fri, Nov 20, 2015 at 2:53 AM, Marcus Weseloh <mweselo...@gmail.com> wrote: > Adds support and documentation for a new slave device property > "sun4i,spi-wdelay" that allows to set the SPI Wait Clock Register per > device / transfer. The SPI hardware will wait the specified amount of > SPI clock periods (plus a constant 3 clock periods) before transmitting > the next word. Should you possibly hide the 3 clock periods from the user? I.e. they set whatever they want for the wdelay, we set it to the closest number we can that's greater or equal to what they ask for. 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.
Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines
Hi, On Wed, Nov 18, 2015 at 9:38 PM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 18-11-15 10:46, Philipp Zabel wrote: >> >> Hi Hans, >> >> Am Montag, den 16.11.2015, 18:13 +0100 schrieb Hans de Goede: >>> >>> On 16-11-15 18:01, Philipp Zabel wrote: >>>> >>>> If there are two devices sharing the same reset line that is initially >>>> held asserted, do the two drivers somehow have to synchronize before >>>> releasing the reset together? >>> >>> >>> Not to my knowledge, I suggest that we simply treat this same as >>> regulators / clocks where the first one to enable it actually gets >>> it enabled (de-asserted in case of a reset), and the last one >>> to disable (assert) it (so dropping the usage counter back to 0) leads >>> to it being asserted again. >>> >>> This seems to work well enough for clocks / regulators and phys, and >>> at least for my use-case it should work fine for the shared reset too >>> (I will test to make sure of course). >>> >>> So from my pov a simple counter should suffice, does that work for you ? >> >> >> I don't quite understand what counting will help with, then. The first >> driver to call reset_control_deassert will deassert the reset, whether >> you count or not. >> But if the two drivers have deasserted an initially asserted reset, a >> reset_control_assert for one of them will silently fail. > > > Correct, which is what we want, although I would not call it silently > fail I would call it a nop as it is intended. > >> I fear the deassertion count maps well to the case where resets are used >> just like clocks (when inactive modules are kept in reset), but I'm not >> sure this is useful in the case of resets that are kept deasserted most >> of the time, only to be asserted for a short pulse. Maybe we have to >> differentiate between the two cases? > > > Ack. I think that the "just like clocks" case is the more common one, and > it seems to me that the short-pulse case should use reset_control_reset. > > Maybe we need to provide a default implementation of reset_control_reset > which > does the pulse when no implementation is provided by the driver ? > > Although that brings the question with it what to do with the deassert_count > in > that case, as some drivers may also use that for the initial deassert... I > guess > we could document to not do that if you want to assure that no other drivers > muck with the reset-line ... > > Hmm, this is getting messy pretty quickly. New proposal: > > 1) Add a concept of shared resets, adding: reset_control_get_shared and >devm_reset_control_get_shared functions, which set a shared bool >in struct reset_control Assuming board designers are sufficiently ... stupid, won't most drivers eventually need to use the _shared variants? Wouldn't it be (horrifically more complicated and) better to just build this into the generic code and switch on the shared reset line handling if multiple devices take references to the same reset line? (Can we run through the device tree and mark them in advance? What happens with overlays?) That said, I suspect that to deal sensibly with shared reset lines we're also going to need some way to init devices in lockstep with others, i.e. we can't deassert device A until it's clocks are running, however the reset line is shared with device B who also can't be deasserted until it's clocks are running. This seems like it'll get rather complicated quickly, to say the least. It almost seems that, unless some other board has a similarly broken design, that it might almost be easier to just make variants of generic-ehci and generic-ohci to handle this one particular case. > 2) Add int refcnt to struct reset_controller_dev, which gets >incremented/decremented on reset_control_get/reset_control_put >do a BUG_ON on refcnt == 1 in the get functions when the non-shared >variant gets called (this is optional but probably a good extra >check) > > 3) Do the whole deassert_count thingy only when the shared bool is true > > 4) Make reset_control_reset fail (BUG_ON) if the shared bool is true > > Regards, > > Hans > > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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.
Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines
Hi All, On Wed, Nov 18, 2015 at 9:18 PM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Wed, Nov 18, 2015 at 10:46:52AM +0100, Philipp Zabel wrote: >> Hi Hans, >> >> Am Montag, den 16.11.2015, 18:13 +0100 schrieb Hans de Goede: >> > On 16-11-15 18:01, Philipp Zabel wrote: >> > > If there are two devices sharing the same reset line that is initially >> > > held asserted, do the two drivers somehow have to synchronize before >> > > releasing the reset together? >> > >> > Not to my knowledge, I suggest that we simply treat this same as >> > regulators / clocks where the first one to enable it actually gets >> > it enabled (de-asserted in case of a reset), and the last one >> > to disable (assert) it (so dropping the usage counter back to 0) leads >> > to it being asserted again. >> > >> > This seems to work well enough for clocks / regulators and phys, and >> > at least for my use-case it should work fine for the shared reset too >> > (I will test to make sure of course). >> > >> > So from my pov a simple counter should suffice, does that work for you ? >> >> I don't quite understand what counting will help with, then. The first >> driver to call reset_control_deassert will deassert the reset, whether >> you count or not. >> But if the two drivers have deasserted an initially asserted reset, a >> reset_control_assert for one of them will silently fail. > > Then maybe we can just make it return an error when someone calls > _assert or _reset on a reset line that has more than one user? Just to set another cat amongst the pigeons: What if a driver needs to toggle the shared reset line of some IP block to get it out of some broken state? 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.
Re: [linux-sunxi] Re: [PATCH sunxi-tools 2/2] fel: Enable MMU on Allwinner-H3
Hi Stefan, On Thu, Nov 12, 2015 at 12:20 AM, Stefan Monnier <monn...@iro.umontreal.ca> wrote: >> When the CPU clock speed is set to 480 MHz by the U-Boot SPL, >^^^ > You mean MBUS? > >> the performance improvement for 'sunxi-fel write' transfers >> to DRAM is ~95 KB/s -> ~510 KB/s. > >> When the CPU clock speed is set to 1008 MHz by the U-Boot SPL, >> the performance improvement for 'sunxi-fel write' transfers >> to DRAM is ~180 KB/s -> ~510 KB/s. > > I don't understand the relation between the above 2 improvements. > What change causes the speed to go from 95KB/s to 180KB/s? My interpretation of this was that before this change, the transfer speed was somehow limited by the clock speed. With the MMU enabled, it appears that the clock speed is no-longer the limiting factor. (I'm _guessing_ that the transfer has to bounce through the CPU and this was slow without the MMU for some reason. I'm also guessing that enabling the MMU has moved the bottleneck elsewhere - possibly the USB hardware.) 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.
Re: [linux-sunxi] [PATCH v4 2/6] clk: sunxi: Add H3 clocks support
Hi Maxime,
On Thu, Nov 5, 2015 at 3:23 AM, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> Hi Julian,
>
> On Wed, Oct 28, 2015 at 10:12:09AM +1100, Julian Calaby wrote:
>> > + of_property_for_each_u32(node, "clock-indices", prop, p, index) {
>> > + of_property_read_string_index(node, "clock-output-names",
>> > + i, _name);
>> > +
>> > + if (index == 17 || (index >= 29 && index <= 31))
>> > + clk_parent = AHB2;
>> > + else if (index <= 63 || index >= 128)
>> > + clk_parent = AHB1;
>> > + else if (index >= 64 && index <= 95)
>> > + clk_parent = APB1;
>> > + else if (index >= 96 && index <= 127)
>> > + clk_parent = APB2;
>>
>> A way to make this reusable in the future might be to encode it in a
>> structure like:
>>
>> static const struct bus_clock_paths sun8i_h3_bus_clock_paths __initdata = {
>> {.parent = 2, .min = 17, .max = 17}, /* index 17 is from AHB2 */
>> {.parent = 2, .min = 29, .max = 31}, /* AHB2 bank */
>> {.parent = 1, .min = 63, .max = 128}, /* AHB1 bank */
>> ...
>> {}
>> };
>>
>> Then the code here can be reused for other clocks like this in the
>> future without too much bloat. (And this would potentially could be
>> generic enough for other platforms.)
>
> We don't really need that at the moment. There's not point in writing
> more complicated code to support a use case we don't have yet.
>
> (However, something along these lines will definitely be needed if we
> ever have another SoC having the same bus gates madness)
This was a suggestion for the future to address Jens' comment about
having a bus clock driver instead of encoding it in devicetree.
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.
Re: [linux-sunxi] [PATCH v4 2/6] clk: sunxi: Add H3 clocks support
me(node));
> + if (IS_ERR(reg))
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(clocks); i++) {
> + index = of_property_match_string(node, "clock-names",
> clocks[i]);
> + if (index < 0)
> + return;
> +
> + clocks[i] = of_clk_get_parent_name(node, index);
> + }
> +
> + clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
> + if (!clk_data)
> + goto err_unmap;
> +
> + number = of_property_count_u32_elems(node, "clock-indices");
> + of_property_read_u32_index(node, "clock-indices", number - 1,
> );
> +
> + clk_data->clks = kcalloc(number + 1, sizeof(struct clk *),
> GFP_KERNEL);
> + if (!clk_data->clks)
> + goto err_free_data;
> +
> + i = 0;
> + of_property_for_each_u32(node, "clock-indices", prop, p, index) {
> + of_property_read_string_index(node, "clock-output-names",
> + i, _name);
> +
> + if (index == 17 || (index >= 29 && index <= 31))
> + clk_parent = AHB2;
> + else if (index <= 63 || index >= 128)
> + clk_parent = AHB1;
> + else if (index >= 64 && index <= 95)
> + clk_parent = APB1;
> + else if (index >= 96 && index <= 127)
> + clk_parent = APB2;
A way to make this reusable in the future might be to encode it in a
structure like:
static const struct bus_clock_paths sun8i_h3_bus_clock_paths __initdata = {
{.parent = 2, .min = 17, .max = 17}, /* index 17 is from AHB2 */
{.parent = 2, .min = 29, .max = 31}, /* AHB2 bank */
{.parent = 1, .min = 63, .max = 128}, /* AHB1 bank */
...
{}
};
Then the code here can be reused for other clocks like this in the
future without too much bloat. (And this would potentially could be
generic enough for other platforms.)
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.
Re: [linux-sunxi] [PATCH 2/6] clk: sunxi: Add H3 clocks support
Hi Jens,
On Thu, Oct 22, 2015 at 3:13 AM, Jens Kuske <jensku...@gmail.com> wrote:
> The H3 clock control unit is similar to the those of other sun8i family
> members like the A23.
>
> It adds a new bus gates clock similar to the simple gates, but with a
> different parent clock for each single gate.
> Some of the gates use the new AHB2 clock as parent, whose clock source
> is muxable between AHB1 and PLL6/2. 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 <jensku...@gmail.com>
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 2 +
> drivers/clk/sunxi/Makefile| 1 +
> drivers/clk/sunxi/clk-bus-gates.c | 105
> ++
> drivers/clk/sunxi/clk-sunxi.c | 12 ++-
> 4 files changed, 117 insertions(+), 3 deletions(-)
> create mode 100644 drivers/clk/sunxi/clk-bus-gates.c
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 7c4aee0..6293c65 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
This hunk should be in patch 1:
> @@ -1000,9 +1005,8 @@ static void __init sunxi_divs_clk_setup(struct
> device_node *node,
>
> for (i = 0; i < SUNXI_DIVS_BASE_NAME_MAX_LEN - 1 &&
> clk_name[i] != '_' &&
> - clk_name[i] != '\0'; i++) {
> + clk_name[i] != '\0'; i++)
> base_name[i] = clk_name[i];
> - }
>
> base_name[i] = '\0';
> factors.name = base_name;
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.
Re: [linux-sunxi] [PATCH 1/3] mtd: nand: add NAND_NEED_SCRAMBLING option flag
Hi Boris, On Fri, Oct 16, 2015 at 4:17 AM, Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > Some MLC NANDs are sensible to repeated patterns and require data to be Do you mean "sensitive" instead of "sensible"? 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.
Re: [linux-sunxi] [PATCH 3/3] mtd: nand: sunxi: add randomizer support
Hi Boris, On Fri, Oct 16, 2015 at 4:17 AM, Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > Add support for the randomizer engine available in Allwinner's NFC IP. > > Randomization is useful to support modern NAND chips which are sensible to Again, did you mean "sensitive" instead of "sensible"? 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.
Re: [linux-sunxi] [PATCH 2/6] mfd: axp20x: Split the driver into core and i2c bits
Hi Chen-Yu,
On Thu, Oct 15, 2015 at 3:32 AM, Chen-Yu Tsai <w...@csie.org> wrote:
> The axp20x driver assumes the device is i2c based. This is not the
> case with later models, which use a proprietary 2 wire serial bus
> called "Reduced Serial Bus".
>
> This patch follows the example of mfd/wm831x and splits it into
> an interface independet core, and an i2c specific glue layer.
>
> The old MFD_AXP20X Kconfig symbol is kept until sub-device drivers
> and defconfigs have migrated to the new MFD_AXP20X_CORE symbol.
>
> Included but unused header files are removed as well.
>
> Signed-off-by: Chen-Yu Tsai <w...@csie.org>
> ---
> drivers/mfd/Kconfig | 18 -
> drivers/mfd/Makefile| 3 +-
> drivers/mfd/{axp20x.c => axp20x-core.c} | 105 +++---
> drivers/mfd/axp20x-i2c.c| 127
>
> include/linux/mfd/axp20x.h | 33 -
> 5 files changed, 186 insertions(+), 100 deletions(-)
> rename drivers/mfd/{axp20x.c => axp20x-core.c} (87%)
> create mode 100644 drivers/mfd/axp20x-i2c.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 99d63675f073..9ba3feb3f2fc 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -79,15 +79,25 @@ config MFD_BCM590XX
> help
> Support for the BCM590xx PMUs from Broadcom
>
> +# Keep the old symbol until subdevice driver dependencies and defconfigs
> +# have been updated.
> config MFD_AXP20X
> - bool "X-Powers AXP20X"
> + bool "X-Powers AXP series PMICs"
> + select MFD_AXP20X_I2C
Unless something has changed in KConfig, (and my knowledge on this is
likely to be outdated) I don't believe this will work as I don't think
selects don't get propagated like you expect. Have you checked that
all possible configuration options survive make oldconfig and build
without warnings?
Also, unless there's some compelling reason not to, it's probably a
good idea to update the dependent drivers and defconfigs now. (or make
this change in a gentler manner.)
> +
> +config MFD_AXP20X_CORE
> + bool
> select MFD_CORE
> - select REGMAP_I2C
> select REGMAP_IRQ
> +
> +config MFD_AXP20X_I2C
> + bool "X-Powers AXP series I2C PMICs"
> + select MFD_AXP20X_CORE
> + select REGMAP_I2C
> depends on I2C=y
> help
> - If you say Y here you get support for the X-Powers AXP202, AXP209
> and
> - AXP288 power management IC (PMIC).
> + If you say Y here you get support for the X-Powers AXP series I2C
> + based power management ICs (PMICs).
> This driver include only the core APIs. You have to select
> individual
> components like regulators or the PEK (Power Enable Key) under the
> corresponding menus.
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.
Re: [linux-sunxi] [PATCH v2 5/5] ARM: sun5i: Add C.H.I.P DTS
Maxime, On Wed, Oct 7, 2015 at 3:17 AM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > Hi, > > On Tue, Oct 06, 2015 at 12:15:38PM +1100, Julian Calaby wrote: >> Hi Maxime, >> >> On Tue, Oct 6, 2015 at 1:23 AM, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >> > The C.H.I.P. is a small SBC with an Allwinner R8, 8GB of NAND, 512MB of >> > RAM, USB host and OTG, a wifi / bluetooth combo chip, an audio/video jack >> > and two connectors to plug additional boards on top of it. >> >> Sorry for the late review, but a couple of minor things stuck out at me. > > No problem :) > >> > Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com> >> > Reviewed-by: Hans de Goede <hdego...@redhat.com> >> > --- >> > arch/arm/boot/dts/Makefile | 3 +- >> > arch/arm/boot/dts/sun5i-r8-chip.dts | 224 >> > >> > 2 files changed, 226 insertions(+), 1 deletion(-) >> > create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts >> > >> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> > index c7adaa85ef3f..2cf7e593270a 100644 >> > --- a/arch/arm/boot/dts/Makefile >> > +++ b/arch/arm/boot/dts/Makefile >> > @@ -600,7 +600,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \ >> > sun5i-a13-olinuxino.dtb \ >> > sun5i-a13-olinuxino-micro.dtb \ >> > sun5i-a13-q8-tablet.dtb \ >> > - sun5i-a13-utoo-p66.dtb >> > + sun5i-a13-utoo-p66.dtb \ >> > + sun5i-r8-chip.dtb >> > dtb-$(CONFIG_MACH_SUN6I) += \ >> > sun6i-a31-app4-evb1.dtb \ >> > sun6i-a31-colombus.dtb \ >> > diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts >> > b/arch/arm/boot/dts/sun5i-r8-chip.dts >> > new file mode 100644 >> > index ..08ff70601c79 >> > --- /dev/null >> > +++ b/arch/arm/boot/dts/sun5i-r8-chip.dts >> > @@ -0,1 +1,224 @@ >> > +/* >> > + * Copyright 2015 Free Electrons >> > + * Copyright 2015 NextThing Co >> > + * >> > + * Maxime Ripard <maxime.rip...@free-electrons.com> >> > + * >> > + * This file is dual-licensed: you can use it either under the terms >> > + * of the GPL or the X11 license, at your option. Note that this dual >> > + * licensing only applies to this file, and not this project as a >> > + * whole. >> > + * >> > + * a) This file 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 file 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. >> > + * >> > + * Or, alternatively, >> > + * >> > + * b) Permission is hereby granted, free of charge, to any person >> > + * obtaining a copy of this software and associated documentation >> > + * files (the "Software"), to deal in the Software without >> > + * restriction, including without limitation the rights to use, >> > + * copy, modify, merge, publish, distribute, sublicense, and/or >> > + * sell copies of the Software, and to permit persons to whom the >> > + * Software is furnished to do so, subject to the following >> > + * conditions: >> > + * >> > + * The above copyright notice and this permission notice shall be >> > + * included in all copies or substantial portions of the Software. >> > + * >> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, >> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES >> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND >> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT >> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, >> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR >> > + * OTHER DEALINGS IN THE SOFTWARE. >> > + */ >> > + >> > +/dts-v1/; &
Re: [linux-sunxi] [PATCH v2 5/5] ARM: sun5i: Add C.H.I.P DTS
Hi Maxime,
On Tue, Oct 6, 2015 at 1:23 AM, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> The C.H.I.P. is a small SBC with an Allwinner R8, 8GB of NAND, 512MB of
> RAM, USB host and OTG, a wifi / bluetooth combo chip, an audio/video jack
> and two connectors to plug additional boards on top of it.
Sorry for the late review, but a couple of minor things stuck out at me.
> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> Reviewed-by: Hans de Goede <hdego...@redhat.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/sun5i-r8-chip.dts | 224
>
> 2 files changed, 226 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c7adaa85ef3f..2cf7e593270a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -600,7 +600,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a13-olinuxino.dtb \
> sun5i-a13-olinuxino-micro.dtb \
> sun5i-a13-q8-tablet.dtb \
> - sun5i-a13-utoo-p66.dtb
> + sun5i-a13-utoo-p66.dtb \
> + sun5i-r8-chip.dtb
> dtb-$(CONFIG_MACH_SUN6I) += \
> sun6i-a31-app4-evb1.dtb \
> sun6i-a31-colombus.dtb \
> diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts
> b/arch/arm/boot/dts/sun5i-r8-chip.dts
> new file mode 100644
> index ..08ff70601c79
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
> @@ -0,1 +1,224 @@
> +/*
> + * Copyright 2015 Free Electrons
> + * Copyright 2015 NextThing Co
> + *
> + * Maxime Ripard <maxime.rip...@free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun5i-a13.dtsi"
Am I missing something or should this include "sun5i-r8.dtsi" instead?
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "NextThing C.H.I.P.";
> + compatible = "nextthing,chip", "allwinner,sun5i-r8";
> +
> + aliases {
> + i2c0 =
> + i2c1 =
> + i2c2 =
> + serial0 =
> + serial1 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
Should the composite output be enabled here too?
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.
Re: [linux-sunxi] [PATCH v2 2/4] ARM: dts: sun4i: gemei-g9: Convert to use axp209 regulator nodes
Hi Priit, On Wed, Sep 23, 2015 at 5:38 PM, Priit Laes <pl...@plaes.org> wrote: > Add regulator nodes for axp209 by including the axp209 dtsi. > > Changes in v2: > - Add the ohci0 node. Firstly, changelog stuff like this should be below the --- under your SOB. Also, shouldn't enabling the ohci0 node be a separate patch? 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.
Re: [linux-sunxi] Re: [PATCH 3/6] sunxi: Add the R8 DTSI
Hi, On Sat, Sep 19, 2015 at 1:39 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 09/18/2015 11:39 AM, Tom Rini wrote: >> >> On Fri, Sep 18, 2015 at 11:17:00AM -0400, Hans de Goede wrote: >>> >>> Hi, >>> >>> On 09/18/2015 11:02 AM, Tom Rini wrote: >>>> >>>> On Fri, Sep 18, 2015 at 02:06:17PM +0200, Maxime Ripard wrote: >>>> >>>>> The R8 is very close to the A13, but it still has a few differences, >>>>> notably a composite output, which the A13 lacks. >>>>> >>>>> Add a DTSI based on the A13's to hold those differences. >>>>> >>>>> Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com> >>>> >>>> >>>> Other than needing to use SPDX tags instead: >>>> Reviewed-by: Tom Rini <tr...@konsulko.com> >>> >>> >>> This is in essence a partial sync with the kernel tree wrt the dts >>> files, so no SPDX tags. >> >> >> Really? I'd have sworn that we were doing that even on kernel files, > > > I don't know. I'm fine either way, but I do not think we should be > adding SPDX tags on the u-boot side only for these files, since those > will just get overwritten (removed) on the next sync with the kernel. Would it make sense to just add them kernel side? 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.
Re: [linux-sunxi] [PATCH v5 2/2] can: Allwinner A10/A20 CAN Controller support - controller code
Hi Gerd, On Sun, Sep 13, 2015 at 11:42 PM, Gerhard Bertelsmann <i...@gerhard-bertelsmann.de> wrote: > General remark: > > Somebody asked me to add linux-sunxi dev list. Seems to be not a good idea > before the driver was ready. Seems to be hard to fulfill the differentness. > > I will remove linux-sunxi for the next patch set. I will try to get > linux-can > people satisfied and then I'm done with it. I'm doing this in my spare time, > but it seems to get an endless story. I'm not offended in any kind, my spare > time is just limited. > > The driver is working so far and the patches also apply to 4.3. You misunderstand, the sunxi people (who's mailing list I follow) are the experts on the hardware platform you're writing this driver for. If you don't include them and don't solicit their advice, your driver may end up doing things which aren't correct for the platform (e.g. it might work for you but break something else) and this will seriously impact it's chances of getting included in the kernel at some point. You also can't get the driver "ready" before asking for their comments as what might have been small tweaks to get stuff "right" at the start may end up being big changes at the end. (Stitch in time and all that.) Including the linux-sunxi mailing list also means that there's more visibility to your efforts, more people looking over the code, (potentially) more testers and less duplicated effort as all sunxi related stuff is referred to in one place. (Thankfully in your case nobody else was working on a CAN bus driver, but there have been cases of multiple people independently working on drivers for the same hardware and only discovering this late in the development process.) As an occasional Linux developer, I don't see Maxime's questions as being "hard": he makes some good points about your clock handling - which is important for power management - and asks a couple of other good questions. Those questions and issues are stuff that has to be answered to get this driver into the kernel. In particular, the question about the interrupt handling was an "explain why you're doing this" question not a "this is broken and needs changing" question. And as for the changing things only to change them back issue, this is likely to be the last time that happens. My reading of his comments indicates that you should check over what and how stuff is handled over the "lifetime" of the device / connection / socket. I.e. are all your resources "freed" after they're no-longer needed? Are you switching off everything you turn on? etc. This is the sort of analysis that I'm sure you've done already, but it never hurts to do it again. I find issues like this all the time in the development I do. Finally, I strongly urge you to stick with the driver at least until it's merged. The fact that Maxime only had a few comments indicates that you've written a good driver which is a few tweaks away from being merged - which is something you should be very proud of. I see drivers being submitted that have much more serious issues and that prompt much more debate than yours has. (For instance I've seen some changes on another mailing list go through 6 full rewrites without everyone being happy.) Excellent work, keep it up. 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.
Re: [linux-sunxi] Re: Re-using sun5i-a13.dtsi for the r8 ?
Hi Maxime, On Tue, Aug 25, 2015 at 12:26 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Fri, Aug 21, 2015 at 09:53:07AM +0200, Hans de Goede wrote: I just realized that I never answered your question about the need for a tvencoder simplefb node in sun5i-a13.dtsi, like the one from the ARM: dts: sun5i: Add simplefb node for tvencoder output I think the real question is do we want to use sun5i-a13.dtsi for the r8 ? So far, the only information I got about the R8 was that it was strictly identical to the A13, and it was making sense to re-use it entirely. Does having the tvout pin change the pinmux options or is that pin strictly single use? (And if it is strictly single use, is adding that pin the entirety of the software visible hardware changes?) I would expect us to use a sun5i-r8.dtsi, this one could then include sun5i-a13.dtsi, and have the extra simplefb node for the tvencoder. Putting the simplefb node for the tvencoder in sun5i-a13.dtsi feels wrong because the A13 package does not have a tvout pin. But if it turns out it's not, then yeah, we'll have to make another DTSI. IMHO that's enough of a change to warrant a new DTSI, I feel that someone's going to use the lack of DTSI as proof that we don't support the R8 or try to use the tv encoder on an A13. 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.
Re: [linux-sunxi] Re: Re-using sun5i-a13.dtsi for the r8 ?
Hi Maxime, On Tue, Aug 25, 2015 at 3:14 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Aug 25, 2015 at 10:24:51AM +1000, Julian Calaby wrote: Hi Maxime, On Tue, Aug 25, 2015 at 12:26 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Fri, Aug 21, 2015 at 09:53:07AM +0200, Hans de Goede wrote: I just realized that I never answered your question about the need for a tvencoder simplefb node in sun5i-a13.dtsi, like the one from the ARM: dts: sun5i: Add simplefb node for tvencoder output I think the real question is do we want to use sun5i-a13.dtsi for the r8 ? So far, the only information I got about the R8 was that it was strictly identical to the A13, and it was making sense to re-use it entirely. Does having the tvout pin change the pinmux options or is that pin strictly single use? (And if it is strictly single use, is adding that pin the entirety of the software visible hardware changes?) I have no idea. I would expect us to use a sun5i-r8.dtsi, this one could then include sun5i-a13.dtsi, and have the extra simplefb node for the tvencoder. Putting the simplefb node for the tvencoder in sun5i-a13.dtsi feels wrong because the A13 package does not have a tvout pin. But if it turns out it's not, then yeah, we'll have to make another DTSI. IMHO that's enough of a change to warrant a new DTSI, Yep. I feel that someone's going to use the lack of DTSI as proof that we don't support the R8 or try to use the tv encoder on an A13. But that argument is dubious. That's not how it works. The list of DTSIs has never been comprehensive list of the supported SoCs. Most definitely. I'm not talking about sensible people here. =) 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.
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Maxime, On Mon, Aug 3, 2015 at 7:34 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote: Hi again, Julian Calaby schrieb am 03.08.2015 06:22: My only real objection here is are there boards that can go down to 0.9v and if so, won't this change make them less power efficient in the almost-idle case? And are those power savings enough to justify not accepting this patch? It will probably make those boards less power efficient, yes. On the other hand, boards that have their CPU regulator set to min. 1.0V might also draw more power because the lowest frequency is not available, even though the savings due to frequency are likely to be lower than the savings due to voltage. Guys, isn't this whole discussion a bit moot? We're not doing any kind of power management but cpufreq, so maybe there's a lot more to do before we actually can have these kind of arguments? Plus this OPP has never been used anyway, so this patch is not going to increase the power consumption either. Oh, I didn't know that. Therefore I withdraw my objections, patch away! 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.
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Chen-Yu, On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai w...@csie.org wrote: Hi, On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby julian.cal...@gmail.com wrote: Hi Timo, On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson public_tim...@silentcreek.de wrote: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. Surely it wouldn't be added here if some could supply 0.9v. On the side, the original OPPs in the FEX files are actually frequency/voltage ranges, and not just points. Mainlines OPPv2 will support these, along with turbo frequencies. Ah, that makes sense. Furthermore, the FEX files also have fields that limit the minimum and maximum frequencies. Is this going to be supported by OPPv2 too? Is the code that uses this smart enough to sensibly switch between two operating points with the same frequency and different voltages? If so, maybe just add a 144MHz @ 1.0v operating point? You could try. Though I really don't see much to gain here. From what I recall, lower frequency = less power usage, though my experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing a lot of details. This is the sort of thing that requires thorough testing on a dev board. (Alternatively, would it make sense to modify the code that uses this to use frequencies with voltages specified that are lower than can be supplied with the lowest voltage it can?) I think that's a bit harder to get accepted. Oh, definitely. It kinda makes sense, but at the same time it'll require some seriously thorough testing on a lot of different boards. My only real objection here is are there boards that can go down to 0.9v and if so, won't this change make them less power efficient in the almost-idle case? And are those power savings enough to justify not accepting this patch? 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.
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Timo, On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson public_tim...@silentcreek.de wrote: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. Surely it wouldn't be added here if some could supply 0.9v. Is the code that uses this smart enough to sensibly switch between two operating points with the same frequency and different voltages? If so, maybe just add a 144MHz @ 1.0v operating point? (Alternatively, would it make sense to modify the code that uses this to use frequencies with voltages specified that are lower than can be supplied with the lowest voltage it can?) 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.
Re: [linux-sunxi] Further Allwinner misbehaviour.
Hi Henrik, On Mon, Jun 29, 2015 at 10:33 AM, Henrik Nordström hen...@henriknordstrom.net wrote: fre 2015-06-26 klockan 01:12 +1000 skrev Julian Calaby: It's obvious what is required: 1. Datasheets 2. Programming manuals 3. GPL compliant drivers 4. (L)GPL compliant userspace stuff and maybe 5. Some on-going contribution to the community And 6. That community uses and improves the free alternatives developed by the community instead of encouraging further bad actions in paths that is unlikely to ever result in anything meeting the broad community goals. They have #1 and #2 but aren't bothering to release them to us. I honestly do not believe they have any better manuals or datasheets than released. They have tons of other internal information (notes, CPU source code, talking with the person who wrote the CPU parts, etc) I'd actually forgotten about their documentation github repository when I wrote this, so I retract this point. They've gotten much better at releasing documentation. I believe the only thing they haven't directly released is documentation for the R8. I believe most of the documentation we have has been obtained through third parties. In past yes kind of.. but now we have https://github.com/allwinner-zh/documents/ Which had slipped my mind. Sigh. #3 is almost happening, but with just about every code release, there's something in there violating the licence. Community have also come very far in making clean GPL drivers for most components, including CedarX. Oh, definitely. Cedarus appears to be as complete, if not more complete than their official drivers. The mainline drivers I've seen appear to be better than what Allwinner produces in almost every way. My point here is that this is due to the community's efforts, not Allwinner's. We're arguing over their lack of ability on #4 and their employees (with the possible exception of Kevin, who pops up every so often to announce something) are absent from the community. This isn't hard, there are thousands of companies doing it. No, we are arguing over AW repeatedly doing the same licensing mistakes. Which makes the stuff they release not (L)GPL compliant. As I see it, this is the same thing, just stated differently, but then I take an absolutist view on licence compliance. Absense from the community is not strange. From a community perspective it would be very desireable that AW employees were more active in the community, but I fully understand that this is not an easy task to accomplish. Most AW employees have access to internal information, and likely bound by restrictions in both contract and cultural difference. I understand that it's difficult, however a lot of companies have succeeded in this. My knowledge of this is mostly from the WiFi subsystem where the entire community is (for the most part) lead by people employed by Intel, Qualcomm and Broadcom. Yes, they are huge companies and Allwinner is tiny in comparison, but I'm not expecting them to run our community here, all I'm hoping for someone who'll essentially be a gateway between Allwinner corporate and us. Even if they just pass out documentation, snippets of code and answer technical questions promptly, (or if they can't answer them, explain why) that'll be enough. Kevin appears to be doing most of that, but he's not very active. 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.
