[linux-sunxi] [PATCH v2 1/1] add missing UARTs pins and I2C entriesfor AllWinner H3 DTSI
Hi everyone,
This patch is submit to provide endusers access to additional UARTs on
AllWinner H3 SoC along with I2C ports.
Regards,
Martin.
---
arch/arm/boot/dts/sun8i-h3.dtsi | 75 +
1 file changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 4a4926b..c947360d 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -508,6 +508,48 @@
allwinner,pull = ;
};
+uart1_pins_a: uart1@0 {
+allwinner,pins = "PG6", "PG7";
+allwinner,function = "uart1";
+allwinner,drive = ;
+allwinner,pull = ;
+};
+
+uart2_pins_a: uart2@0 {
+allwinner,pins = "PA0", "PA1";
+allwinner,function = "uart2";
+allwinner,drive = ;
+allwinner,pull = ;
+};
+
+uart3_pins_a: uart3@0 {
+allwinner,pins = "PA13", "PA14";
+allwinner,function = "uart3";
+allwinner,drive = ;
+allwinner,pull = ;
+};
+
+i2c0_pins_a: i2c0@0 {
+allwinner,pins = "PA11", "PA12";
+allwinner,function = "i2c0";
+allwinner,drive = ;
+allwinner,pull = ;
+};
+
+i2c1_pins_a: i2c1@0 {
+allwinner,pins = "PA18", "PA19";
+allwinner,function = "i2c1";
+allwinner,drive = ;
+allwinner,pull = ;
+};
+
+i2c2_pins_a: i2c2@0 {
+allwinner,pins = "PE12", "PE13";
+allwinner,function = "i2c2";
+allwinner,drive = ;
+allwinner,pull = ;
+};
+
mmc0_pins_a: mmc0@0 {
allwinner,pins = "PF0", "PF1", "PF2", "PF3",
"PF4", "PF5";
@@ -626,6 +668,39 @@
status = "disabled";
};
+i2c0: i2c@01c2ac00 {
+compatible = "allwinner,sun6i-a31-i2c";
+reg = <0x01c2ac00 0x400>;
+interrupts = ;
+clocks = <&bus_gates 96>;
+resets = <&apb2_rst 0>;
+status = "disabled";
+#address-cells = <1>;
+#size-cells = <0>;
+};
+
+i2c1: i2c@01c2b000 {
+compatible = "allwinner,sun6i-a31-i2c";
+reg = <0x01c2b000 0x400>;
+interrupts = ;
+clocks = <&bus_gates 97>;
+resets = <&apb2_rst 1>;
+status = "disabled";
+#address-cells = <1>;
+#size-cells = <0>;
+};
+
+i2c2: i2c@01c2b400 {
+compatible = "allwinner,sun6i-a31-i2c";
+reg = <0x01c2b400 0x400>;
+interrupts = ;
+clocks = <&bus_gates 98>;
+resets = <&apb2_rst 2>;
+status = "disabled";
+#address-cells = <1>;
+#size-cells = <0>;
+};
+
gic: interrupt-controller@01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
--
2.7.4
--
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 v1 1/1] add missing UARTs pins for AllWinner H3 DTS + add new I2C entries for AllWinner H3 DTS
On 19 April 2016 at 17:11, Chen-Yu Tsai wrote: > On Tue, Apr 19, 2016 at 10:46 PM, wrote: >> Hi ChenYu, >> >> Thanks for your comments. >> >> On Tuesday, April 19, 2016 at 7:11:50 AM UTC-4, Chen-Yu Tsai wrote: >>> Hi, >>> >>> > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 36 ++ >>> > arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 36 ++ >>> > arch/arm/boot/dts/sun8i-h3.dtsi| 75 >>> >>> First of all, you are touching 3 different files here. These should >>> be separate patches. >> >> I'm trying to understand you here, but I can't. Those 3 files changed are >> related each other. I could have separated the UART changes from I2C >> changes, but still those 3 files would have been modified at the same time >> for a single commit and "git patch-format" would still have created a single >> patch for the 3 files commit. > > Try to wrap lines to 80 characters or less. > > 1 change per patch. You are making 3 changes here. a) adding shared > pinmux settings, > b & c) enabling uarts and i2c busses for 2 boards. > > You could split them into 1 dtsi patch adding the pinmux setting, and > then 1 for each > board enabling the peripherals. > >> >> Seeing all the patches that coming into the mailing lists, all of them >> contains multiple files patches, why should it be different here ? >> >>> >>> Secondly, our policy is to not have a default function for generic GPIO >>> pins. >>> >> >> If this is the official policy, then why so many DTS currently present are >> not following the same rules, such sun6i-a31-hummingbird, >> sun7i-a20-olinuxino-micro, sun7i-a20-mk808c, sun7i-a20-cubietruck and so >> many others ? > > Perhaps they were enabled before the policy was enacted, or it just > slipped through. I > contributed to a few. But for many boards we might not have schematics > or the actual > device to check. > > Also, other boards having such settings is not a good argument. +1 for what Wen is saying here. If the pins go to a header then it's best to leave it as a GPIO. Uart2 on the mk808c is enabled as it's used for Bluetooth. CK > >> I thought the rules were there to make DTS the most default common usage >> definitions for most end-users in a general availability. >> Then, if someone is really in shortage of GPIOs, they could easily turn them >> back to "disabled" state. > > How would you determine what the most common usage is for "development > boards"? > If the vendor explicitly designed the pins to be used one way, and even > printed > the description on the board, then you may have a valid argument. But even > then, > with the C.H.I.P., they are going with DT overlays. > > It shouldn't be hard for an end user to modify the DT. And with I2C devices, > it > is almost a requirement. > > > Regards > ChenYu > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v1 1/1] add missing UARTs pins for AllWinner H3 DTS + add new I2C entries for AllWinner H3 DTS
Oupps ! sorry for again have a line length exceeding 80 chars. Regards, -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v1 1/1] add missing UARTs pins for AllWinner H3 DTS + add new I2C entries for AllWinner H3 DTS
On Tuesday, April 19, 2016 at 11:11:37 AM UTC-4, Chen-Yu Tsai wrote: > Try to wrap lines to 80 characters or less. Ok ! I will be more careful ... > 1 change per patch. You are making 3 changes here. a) adding shared > pinmux settings, > b & c) enabling uarts and i2c busses for 2 boards. > > You could split them into 1 dtsi patch adding the pinmux setting, and > then 1 for each > board enabling the peripherals. Fine ! I will prepare and redo a new submit with only the DTSI for now. > Perhaps they were enabled before the policy was enacted, or it just > slipped through. I > contributed to a few. But for many boards we might not have schematics > or the actual > device to check. Understood ! But sometimes things are so generic, like having uart0 and not having uart1 make it looks a bit strange. Some other times having some i2c2 because of PMIC while not having i2c0 and i2c1 is also strange. > How would you determine what the most common usage is for "development > boards"? > If the vendor explicitly designed the pins to be used one way, and even > printed > the description on the board, then you may have a valid argument. But even > then, > with the C.H.I.P., they are going with DT overlays. > > It shouldn't be hard for an end user to modify the DT. And with I2C devices, > it > is almost a requirement. Ok ! I will look if it is easier to do the rest with overlays. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2] sunxi factors clock predivider handling
For allwinner A31 ahb1 and a83t ahb1 clocks have predivider for certain parent. Currently, it's being handled in clock specific functions. A83t ahb1 and a31 ahb1 are similar clocks except a83t parent index 0b10 and 0b11 are pll6/prediv and a31 ahb1 parent index 0x11 is pll6/prediv. with only this change, code duplication was needed. To handle this, this patch adds predivider table with parent index, prediv shift and width, parents with predivider will have nonzero width. Rate adjustment is moved from clock specific recalc function to generic factors recalc. clock specific recalc was currently used only by a31 ahb1. For getter, it differentiates parents with prediv, with non-zero prediv width. I've tested this patch on a83t bpi-m3 board. I do not have a31 device. As there are dependencies on other a83t patches, a83t changes are not included in this patch, It'll be included in separate patch. v1->v2 Changes: 1. As 'kbuild test robot' reported build failure due to dependency on patches, Combined two patches in v1 into single patch. Vishnu Patekar (1): clk: sunxi: predivider handling for factors clock drivers/clk/sunxi/clk-factors.c | 31 +++ drivers/clk/sunxi/clk-factors.h | 10 +- drivers/clk/sunxi/clk-sunxi.c | 31 +-- 3 files changed, 33 insertions(+), 39 deletions(-) -- 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.
[linux-sunxi] [PATCH v2] clk: sunxi: predivider handling for factors clock
For A31 ahb1 and a83t ahb1 clocks have predivider for certain parent.
To handle this, this patch adds predivider table with parent index,
prediv shift and width, parents with predivider will have nonzero width.
Rate adjustment is moved from clock specific recalc function to generic
factors recalc. Also, adds prediv table for a31.
Signed-off-by: Vishnu Patekar
---
drivers/clk/sunxi/clk-factors.c | 31 +++
drivers/clk/sunxi/clk-factors.h | 10 +-
drivers/clk/sunxi/clk-sunxi.c | 31 +--
3 files changed, 33 insertions(+), 39 deletions(-)
diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index ddefe96..8f3b637 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -45,10 +45,12 @@ static unsigned long clk_factors_recalc_rate(struct clk_hw
*hw,
unsigned long parent_rate)
{
u8 n = 1, k = 0, p = 0, m = 0;
+ u8 par_index = 0;
u32 reg;
unsigned long rate;
struct clk_factors *factors = to_clk_factors(hw);
const struct clk_factors_config *config = factors->config;
+ const struct clk_factors_prediv *prediv = factors->prediv_config;
/* Fetch the register value */
reg = readl(factors->reg);
@@ -63,24 +65,16 @@ static unsigned long clk_factors_recalc_rate(struct clk_hw
*hw,
if (config->pwidth != SUNXI_FACTORS_NOT_APPLICABLE)
p = FACTOR_GET(config->pshift, config->pwidth, reg);
- if (factors->recalc) {
- struct factors_request factors_req = {
- .parent_rate = parent_rate,
- .n = n,
- .k = k,
- .m = m,
- .p = p,
- };
-
+ if (prediv) {
/* get mux details from mux clk structure */
if (factors->mux)
- factors_req.parent_index =
- (reg >> factors->mux->shift) &
- factors->mux->mask;
-
- factors->recalc(&factors_req);
+ par_index = (reg >> factors->mux->shift) &
+ factors->mux->mask;
- return factors_req.rate;
+ if (prediv[par_index].width != SUNXI_FACTORS_NOT_APPLICABLE) {
+ m = FACTOR_GET(prediv[par_index].shift,
+ prediv[par_index].width, reg);
+ }
}
/* Calculate the rate */
@@ -102,8 +96,12 @@ static int clk_factors_determine_rate(struct clk_hw *hw,
for (i = 0; i < num_parents; i++) {
struct factors_request factors_req = {
.rate = req->rate,
- .parent_index = i,
};
+
+ if (factors->prediv_config)
+ factors_req.prediv_width =
+ factors->prediv_config[i].width;
+
parent = clk_hw_get_parent_by_index(hw, i);
if (!parent)
continue;
@@ -211,6 +209,7 @@ struct clk *sunxi_factors_register(struct device_node *node,
/* set up factors properties */
factors->reg = reg;
factors->config = data->table;
+ factors->prediv_config = data->prediv_table;
factors->get_factors = data->getter;
factors->recalc = data->recalc;
factors->lock = lock;
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index 1e63c5b..b1b7745 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -18,10 +18,16 @@ struct clk_factors_config {
u8 n_start;
};
+struct clk_factors_prediv {
+ u8 parent_index;
+ u8 shift;
+ u8 width;
+};
+
struct factors_request {
unsigned long rate;
unsigned long parent_rate;
- u8 parent_index;
+ u8 prediv_width;
u8 n;
u8 k;
u8 m;
@@ -33,6 +39,7 @@ struct factors_data {
int mux;
int muxmask;
const struct clk_factors_config *table;
+ const struct clk_factors_prediv *prediv_table;
void (*getter)(struct factors_request *req);
void (*recalc)(struct factors_request *req);
const char *name;
@@ -42,6 +49,7 @@ struct clk_factors {
struct clk_hw hw;
void __iomem *reg;
const struct clk_factors_config *config;
+ const struct clk_factors_prediv *prediv_config;
void (*get_factors)(struct factors_request *req);
void (*recalc)(struct factors_request *req);
spinlock_t *lock;
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 91de0a0..5a5f26b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -282,8 +282,6 @@ static void sun5i_a13_get_ahb_factors(struct
factors_request *r
[linux-sunxi] Re: [PATCH 1/2] clk: sunxi: add predivider handling for factors clock
Hello Wens,
On Tue, Apr 19, 2016 at 10:16 PM, Chen-Yu Tsai wrote:
> On Tue, Apr 19, 2016 at 6:22 PM, Philip Li wrote:
>> On Sun, Apr 17, 2016 at 11:53:47AM +0800, Vishnu Patekar wrote:
>>> Both of these patches in series has to be applied at the same time.
>>> I think this is the reason, it fails.
>
> You should probably squash the second patch into the first.
Yes, I should have, I'll send v2 by combining both patches into one.
>
> ChenYu
>
>> hi Xiaolong, would you help do a check whether we apply the patches in
>> correct sequence for this case?
>>
>>
>>> On 17 Apr 2016 09:26, "kbuild test robot" wrote:
>>>
>>> > Hi Vishnu,
>>> >
>>> > [auto build test ERROR on clk/clk-next]
>>> > [also build test ERROR on v4.6-rc3 next-20160415]
>>> > [if your patch is applied to the wrong git tree, please drop us a note to
>>> > help improving the system]
>>> >
>>> > url:
>>> > https://github.com/0day-ci/linux/commits/Vishnu-Patekar/sunxi-factors-clock-predivider-handling/20160417-025801
>>> > base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
>>> > clk-next
>>> > config: arm-sunxi_defconfig (attached as .config)
>>> > reproduce:
>>> > wget
>>> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>>> > -O ~/bin/make.cross
>>> > chmod +x ~/bin/make.cross
>>> > # save the attached .config to linux build tree
>>> > make.cross ARCH=arm
>>> >
>>> > Note: the
>>> > linux-review/Vishnu-Patekar/sunxi-factors-clock-predivider-handling/20160417-025801
>>> > HEAD 19bb5fc952754381d9f4f9b2e57a1fa09f467359 builds fine.
>>> > It only hurts bisectibility.
>>> >
>>> > All errors (new ones prefixed by >>):
>>> >
>>> >drivers/clk/sunxi/clk-sunxi.c: In function 'sun6i_get_ahb1_factors':
>>> > >> drivers/clk/sunxi/clk-sunxi.c:310:9: error: 'struct factors_request'
>>> > has no member named 'parent_index'
>>> > if (req->parent_index == SUN6I_AHB1_PARENT_PLL6) {
>>> > ^
>>> >drivers/clk/sunxi/clk-sunxi.c: In function 'sun6i_ahb1_recalc':
>>> >drivers/clk/sunxi/clk-sunxi.c:340:9: error: 'struct factors_request'
>>> > has no member named 'parent_index'
>>> > if (req->parent_index == SUN6I_AHB1_PARENT_PLL6)
>>> > ^
>>> >
>>> > vim +310 drivers/clk/sunxi/clk-sunxi.c
>>> >
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 304 if (req->parent_rate && req->rate
>>> > > req->parent_rate)
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 305 req->rate =
>>> > req->parent_rate;
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 306
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 307 div =
>>> > DIV_ROUND_UP(req->parent_rate, req->rate);
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 308
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 309 /* calculate pre-divider if parent
>>> > is pll6 */
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 @310 if (req->parent_index ==
>>> > SUN6I_AHB1_PARENT_PLL6) {
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 311 if (div < 4)
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 312 calcp = 0;
>>> > a78bb355 Chen-Yu Tsai 2016-01-25 313 else if (div / 2 < 4)
>>> >
>>> > :: The code at line 310 was first introduced by commit
>>> > :: a78bb35552a800949b2bf68f372d3d6ccabdd790 clk: sunxi: rewrite
>>> > sun6i-a31-ahb1-clk using factors clk with custom recalc
>>> >
>>> > :: TO: Chen-Yu Tsai
>>> > :: CC: Maxime Ripard
>>> >
>>> > ---
>>> > 0-DAY kernel test infrastructureOpen Source Technology
>>> > Center
>>> > https://lists.01.org/pipermail/kbuild-all Intel
>>> > Corporation
>>> >
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: random decryption errors with sun4i-ss on dm-crypt
Still nothing :( it seems i can convert my encrypted storage back to XTS, as i've only converted it to CBC for the hw encryption. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/3] dmaengine: sun6i: Upgrade for audio transfers
On Sat, Apr 02, 2016 at 11:49:13AM +0200, Jean-Francois Moine wrote: > This patch series contains most of the required changes to > the sun6i DMA driver for audio streaming (tested in > a Allwinner H3 - Orange PI 2). > It is based on the previous series 'dmaengine: sun6i: Fixes' > (2016-03-18). The series looks good but had one checkpatch error :( I dont seem to have these fixes which explains why this fails for me. Can you please resend the fixes one and rebase this and fix the checkpatch for this and send me Thanks -- ~Vinod -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v1 1/1] add missing UARTs pins for AllWinner H3 DTS + add new I2C entries for AllWinner H3 DTS
On Tue, Apr 19, 2016 at 10:46 PM, wrote: > Hi ChenYu, > > Thanks for your comments. > > On Tuesday, April 19, 2016 at 7:11:50 AM UTC-4, Chen-Yu Tsai wrote: >> Hi, >> >> > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 36 ++ >> > arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 36 ++ >> > arch/arm/boot/dts/sun8i-h3.dtsi| 75 >> >> First of all, you are touching 3 different files here. These should >> be separate patches. > > I'm trying to understand you here, but I can't. Those 3 files changed are > related each other. I could have separated the UART changes from I2C changes, > but still those 3 files would have been modified at the same time for a > single commit and "git patch-format" would still have created a single patch > for the 3 files commit. Try to wrap lines to 80 characters or less. 1 change per patch. You are making 3 changes here. a) adding shared pinmux settings, b & c) enabling uarts and i2c busses for 2 boards. You could split them into 1 dtsi patch adding the pinmux setting, and then 1 for each board enabling the peripherals. > > Seeing all the patches that coming into the mailing lists, all of them > contains multiple files patches, why should it be different here ? > >> >> Secondly, our policy is to not have a default function for generic GPIO pins. >> > > If this is the official policy, then why so many DTS currently present are > not following the same rules, such sun6i-a31-hummingbird, > sun7i-a20-olinuxino-micro, sun7i-a20-mk808c, sun7i-a20-cubietruck and so many > others ? Perhaps they were enabled before the policy was enacted, or it just slipped through. I contributed to a few. But for many boards we might not have schematics or the actual device to check. Also, other boards having such settings is not a good argument. > I thought the rules were there to make DTS the most default common usage > definitions for most end-users in a general availability. > Then, if someone is really in shortage of GPIOs, they could easily turn them > back to "disabled" state. How would you determine what the most common usage is for "development boards"? If the vendor explicitly designed the pins to be used one way, and even printed the description on the board, then you may have a valid argument. But even then, with the C.H.I.P., they are going with DT overlays. It shouldn't be hard for an end user to modify the DT. And with I2C devices, it is almost a requirement. Regards ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v1 1/1] add missing UARTs pins for AllWinner H3 DTS + add new I2C entries for AllWinner H3 DTS
Hi ChenYu, Thanks for your comments. On Tuesday, April 19, 2016 at 7:11:50 AM UTC-4, Chen-Yu Tsai wrote: > Hi, > > > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 36 ++ > > arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 36 ++ > > arch/arm/boot/dts/sun8i-h3.dtsi| 75 > > First of all, you are touching 3 different files here. These should > be separate patches. I'm trying to understand you here, but I can't. Those 3 files changed are related each other. I could have separated the UART changes from I2C changes, but still those 3 files would have been modified at the same time for a single commit and "git patch-format" would still have created a single patch for the 3 files commit. Seeing all the patches that coming into the mailing lists, all of them contains multiple files patches, why should it be different here ? > > Secondly, our policy is to not have a default function for generic GPIO pins. > If this is the official policy, then why so many DTS currently present are not following the same rules, such sun6i-a31-hummingbird, sun7i-a20-olinuxino-micro, sun7i-a20-mk808c, sun7i-a20-cubietruck and so many others ? I thought the rules were there to make DTS the most default common usage definitions for most end-users in a general availability. Then, if someone is really in shortage of GPIOs, they could easily turn them back to "disabled" state. Regards, Martin. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/2] clk: sunxi: add predivider handling for factors clock
On Tue, Apr 19, 2016 at 6:22 PM, Philip Li wrote:
> On Sun, Apr 17, 2016 at 11:53:47AM +0800, Vishnu Patekar wrote:
>> Both of these patches in series has to be applied at the same time.
>> I think this is the reason, it fails.
You should probably squash the second patch into the first.
ChenYu
> hi Xiaolong, would you help do a check whether we apply the patches in
> correct sequence for this case?
>
>
>> On 17 Apr 2016 09:26, "kbuild test robot" wrote:
>>
>> > Hi Vishnu,
>> >
>> > [auto build test ERROR on clk/clk-next]
>> > [also build test ERROR on v4.6-rc3 next-20160415]
>> > [if your patch is applied to the wrong git tree, please drop us a note to
>> > help improving the system]
>> >
>> > url:
>> > https://github.com/0day-ci/linux/commits/Vishnu-Patekar/sunxi-factors-clock-predivider-handling/20160417-025801
>> > base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
>> > clk-next
>> > config: arm-sunxi_defconfig (attached as .config)
>> > reproduce:
>> > wget
>> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>> > -O ~/bin/make.cross
>> > chmod +x ~/bin/make.cross
>> > # save the attached .config to linux build tree
>> > make.cross ARCH=arm
>> >
>> > Note: the
>> > linux-review/Vishnu-Patekar/sunxi-factors-clock-predivider-handling/20160417-025801
>> > HEAD 19bb5fc952754381d9f4f9b2e57a1fa09f467359 builds fine.
>> > It only hurts bisectibility.
>> >
>> > All errors (new ones prefixed by >>):
>> >
>> >drivers/clk/sunxi/clk-sunxi.c: In function 'sun6i_get_ahb1_factors':
>> > >> drivers/clk/sunxi/clk-sunxi.c:310:9: error: 'struct factors_request'
>> > has no member named 'parent_index'
>> > if (req->parent_index == SUN6I_AHB1_PARENT_PLL6) {
>> > ^
>> >drivers/clk/sunxi/clk-sunxi.c: In function 'sun6i_ahb1_recalc':
>> >drivers/clk/sunxi/clk-sunxi.c:340:9: error: 'struct factors_request'
>> > has no member named 'parent_index'
>> > if (req->parent_index == SUN6I_AHB1_PARENT_PLL6)
>> > ^
>> >
>> > vim +310 drivers/clk/sunxi/clk-sunxi.c
>> >
>> > a78bb355 Chen-Yu Tsai 2016-01-25 304 if (req->parent_rate && req->rate
>> > > req->parent_rate)
>> > a78bb355 Chen-Yu Tsai 2016-01-25 305 req->rate =
>> > req->parent_rate;
>> > a78bb355 Chen-Yu Tsai 2016-01-25 306
>> > a78bb355 Chen-Yu Tsai 2016-01-25 307 div =
>> > DIV_ROUND_UP(req->parent_rate, req->rate);
>> > a78bb355 Chen-Yu Tsai 2016-01-25 308
>> > a78bb355 Chen-Yu Tsai 2016-01-25 309 /* calculate pre-divider if parent
>> > is pll6 */
>> > a78bb355 Chen-Yu Tsai 2016-01-25 @310 if (req->parent_index ==
>> > SUN6I_AHB1_PARENT_PLL6) {
>> > a78bb355 Chen-Yu Tsai 2016-01-25 311 if (div < 4)
>> > a78bb355 Chen-Yu Tsai 2016-01-25 312 calcp = 0;
>> > a78bb355 Chen-Yu Tsai 2016-01-25 313 else if (div / 2 < 4)
>> >
>> > :: The code at line 310 was first introduced by commit
>> > :: a78bb35552a800949b2bf68f372d3d6ccabdd790 clk: sunxi: rewrite
>> > sun6i-a31-ahb1-clk using factors clk with custom recalc
>> >
>> > :: TO: Chen-Yu Tsai
>> > :: CC: Maxime Ripard
>> >
>> > ---
>> > 0-DAY kernel test infrastructureOpen Source Technology
>> > Center
>> > https://lists.01.org/pipermail/kbuild-all Intel
>> > Corporation
>> >
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
On 19/04/16 15:41, Boris Brezillon wrote:
> On Tue, 19 Apr 2016 15:30:39 +0300
> Roger Quadros wrote:
>
>> On 19/04/16 14:22, Boris Brezillon wrote:
>>> Hi Roger,
>>>
>>> On Tue, 19 Apr 2016 13:28:50 +0300
>>> Roger Quadros wrote:
>>>
> @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device
> *pdev)
> nand_chip->ecc.correct = omap_correct_data;
> mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
> oobbytes_per_step = nand_chip->ecc.bytes;
> +
> + if (nand_chip->options & NAND_BUSWIDTH_16)
> + min_oobbytes= 1;
Shouldn't this have been
if (!(nand_chip->options & NAND_BUSWIDTH_16)
min_oobbytes= 1;
?
>>>
>>> Yep.
>>>
> break;
>
> case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
> @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device
> *pdev)
> }
>
> /* check if NAND device's OOB is enough to store ECC signatures */
> - min_oobbytes = (oobbytes_per_step *
> - (mtd->writesize / nand_chip->ecc.size)) +
> -(nand_chip->options & NAND_BUSWIDTH_16 ?
> - BADBLOCK_MARKER_LENGTH : 1);
> + min_oobbytes += (oobbytes_per_step *
> + (mtd->writesize / nand_chip->ecc.size));
> if (mtd->oobsize < min_oobbytes) {
> dev_err(&info->pdev->dev,
> "not enough OOB bytes required = %d, available=%d\n",
>
After the above changes BCH with HW ECC worked fine but BCH with SW ECC
still failed.
I had to fix it up with the below patch. This is mainly because
chip->ecc.steps wasn't
yet initialized before calling nand_bch_init().
After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw)
and ham1.
I couldn't yet verify bch16 though.
>>>
>>
>> I just verified that bch16 works as well.
>>
>>> Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
>>> users.
>>>
>>> Could you try this patch?
>>
>> I tried your patch and it worked fine.
>
> Thanks, I'll provide a reworked nand/next branch soon.
> BTW, is there anything to fix in my merge commit (the commit merging
> your GPMC/OMAP changes in nand/next)?
>
I just replied in the other thread that the conflict resolution is fine.
>> You will still need the below change to omap2.c
>>
>> --
>> cheers,
>> -roger
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 0abfba6..33c8fde 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1715,7 +1715,7 @@ static int omap_sw_ooblayout_free(struct mtd_info
>> *mtd, int section,
>> struct nand_chip *chip = mtd_to_nand(mtd);
>> int off = BADBLOCK_MARKER_LENGTH;
>>
>> -if (section)
>> +if (section >= chip->ecc.steps)
>> return -ERANGE;
>
> Sorry but I don't get why we need that one. Don't we have a single
> oobfree section starting at the end of the ECC sections?
>
>
You are right. Nothing needs to be changed there then. Thanks :)
cheers,
-roger
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
On Tue, 19 Apr 2016 15:30:39 +0300
Roger Quadros wrote:
> On 19/04/16 14:22, Boris Brezillon wrote:
> > Hi Roger,
> >
> > On Tue, 19 Apr 2016 13:28:50 +0300
> > Roger Quadros wrote:
> >
> >>> @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device
> >>> *pdev)
> >>> nand_chip->ecc.correct = omap_correct_data;
> >>> mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
> >>> oobbytes_per_step = nand_chip->ecc.bytes;
> >>> +
> >>> + if (nand_chip->options & NAND_BUSWIDTH_16)
> >>> + min_oobbytes= 1;
> >>
> >> Shouldn't this have been
> >>if (!(nand_chip->options & NAND_BUSWIDTH_16)
> >>min_oobbytes= 1;
> >> ?
> >
> > Yep.
> >
> >>
> >>> break;
> >>>
> >>> case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
> >>> @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device
> >>> *pdev)
> >>> }
> >>>
> >>> /* check if NAND device's OOB is enough to store ECC signatures */
> >>> - min_oobbytes = (oobbytes_per_step *
> >>> - (mtd->writesize / nand_chip->ecc.size)) +
> >>> -(nand_chip->options & NAND_BUSWIDTH_16 ?
> >>> - BADBLOCK_MARKER_LENGTH : 1);
> >>> + min_oobbytes += (oobbytes_per_step *
> >>> + (mtd->writesize / nand_chip->ecc.size));
> >>> if (mtd->oobsize < min_oobbytes) {
> >>> dev_err(&info->pdev->dev,
> >>> "not enough OOB bytes required = %d, available=%d\n",
> >>>
> >>
> >> After the above changes BCH with HW ECC worked fine but BCH with SW ECC
> >> still failed.
> >> I had to fix it up with the below patch. This is mainly because
> >> chip->ecc.steps wasn't
> >> yet initialized before calling nand_bch_init().
> >>
> >> After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw)
> >> and ham1.
> >> I couldn't yet verify bch16 though.
> >
>
> I just verified that bch16 works as well.
>
> > Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
> > users.
> >
> > Could you try this patch?
>
> I tried your patch and it worked fine.
Thanks, I'll provide a reworked nand/next branch soon.
BTW, is there anything to fix in my merge commit (the commit merging
your GPMC/OMAP changes in nand/next)?
> You will still need the below change to omap2.c
>
> --
> cheers,
> -roger
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 0abfba6..33c8fde 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1715,7 +1715,7 @@ static int omap_sw_ooblayout_free(struct mtd_info *mtd,
> int section,
> struct nand_chip *chip = mtd_to_nand(mtd);
> int off = BADBLOCK_MARKER_LENGTH;
>
> - if (section)
> + if (section >= chip->ecc.steps)
> return -ERANGE;
Sorry but I don't get why we need that one. Don't we have a single
oobfree section starting at the end of the ECC sections?
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
On 19/04/16 14:22, Boris Brezillon wrote:
> Hi Roger,
>
> On Tue, 19 Apr 2016 13:28:50 +0300
> Roger Quadros wrote:
>
>>> @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device
>>> *pdev)
>>> nand_chip->ecc.correct = omap_correct_data;
>>> mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
>>> oobbytes_per_step = nand_chip->ecc.bytes;
>>> +
>>> + if (nand_chip->options & NAND_BUSWIDTH_16)
>>> + min_oobbytes= 1;
>>
>> Shouldn't this have been
>> if (!(nand_chip->options & NAND_BUSWIDTH_16)
>> min_oobbytes= 1;
>> ?
>
> Yep.
>
>>
>>> break;
>>>
>>> case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
>>> @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device
>>> *pdev)
>>> }
>>>
>>> /* check if NAND device's OOB is enough to store ECC signatures */
>>> - min_oobbytes = (oobbytes_per_step *
>>> - (mtd->writesize / nand_chip->ecc.size)) +
>>> - (nand_chip->options & NAND_BUSWIDTH_16 ?
>>> - BADBLOCK_MARKER_LENGTH : 1);
>>> + min_oobbytes += (oobbytes_per_step *
>>> +(mtd->writesize / nand_chip->ecc.size));
>>> if (mtd->oobsize < min_oobbytes) {
>>> dev_err(&info->pdev->dev,
>>> "not enough OOB bytes required = %d, available=%d\n",
>>>
>>
>> After the above changes BCH with HW ECC worked fine but BCH with SW ECC
>> still failed.
>> I had to fix it up with the below patch. This is mainly because
>> chip->ecc.steps wasn't
>> yet initialized before calling nand_bch_init().
>>
>> After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw) and
>> ham1.
>> I couldn't yet verify bch16 though.
>
I just verified that bch16 works as well.
> Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
> users.
>
> Could you try this patch?
I tried your patch and it worked fine.
You will still need the below change to omap2.c
--
cheers,
-roger
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0abfba6..33c8fde 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1715,7 +1715,7 @@ static int omap_sw_ooblayout_free(struct mtd_info *mtd,
int section,
struct nand_chip *chip = mtd_to_nand(mtd);
int off = BADBLOCK_MARKER_LENGTH;
- if (section)
+ if (section >= chip->ecc.steps)
return -ERANGE;
/*
--
2.5.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
Hi Roger,
On Tue, 19 Apr 2016 13:28:50 +0300
Roger Quadros wrote:
> > @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device
> > *pdev)
> > nand_chip->ecc.correct = omap_correct_data;
> > mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
> > oobbytes_per_step = nand_chip->ecc.bytes;
> > +
> > + if (nand_chip->options & NAND_BUSWIDTH_16)
> > + min_oobbytes= 1;
>
> Shouldn't this have been
> if (!(nand_chip->options & NAND_BUSWIDTH_16)
> min_oobbytes= 1;
> ?
Yep.
>
> > break;
> >
> > case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
> > @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device
> > *pdev)
> > }
> >
> > /* check if NAND device's OOB is enough to store ECC signatures */
> > - min_oobbytes = (oobbytes_per_step *
> > - (mtd->writesize / nand_chip->ecc.size)) +
> > - (nand_chip->options & NAND_BUSWIDTH_16 ?
> > - BADBLOCK_MARKER_LENGTH : 1);
> > + min_oobbytes += (oobbytes_per_step *
> > +(mtd->writesize / nand_chip->ecc.size));
> > if (mtd->oobsize < min_oobbytes) {
> > dev_err(&info->pdev->dev,
> > "not enough OOB bytes required = %d, available=%d\n",
> >
>
> After the above changes BCH with HW ECC worked fine but BCH with SW ECC still
> failed.
> I had to fix it up with the below patch. This is mainly because
> chip->ecc.steps wasn't
> yet initialized before calling nand_bch_init().
>
> After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw) and
> ham1.
> I couldn't yet verify bch16 though.
Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
users.
Could you try this patch?
--->8---
diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index ca9b2a4..3ca3d39 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -177,6 +177,16 @@ struct nand_bch_control *nand_bch_init(struct mtd_info
*mtd)
goto fail;
}
+ /*
+* ecc->steps and ecc->total might be used by mtd->ooblayout->ecc(),
+* which is called by mtd_ooblayout_count_eccbytes().
+* Make sure they are properly initialized before calling
+* mtd_ooblayout_count_eccbytes().
+* FIXME: we should probaly rework the sequencing in nand_scan_tail()
+* to avoid setting those fields twice.
+*/
+ nand->ecc.steps = eccsteps;
+ nand->ecc.total = eccsteps * eccbytes;
if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
printk(KERN_WARNING "invalid ecc layout\n");
goto fail;
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v1 1/1] add missing UARTs pins for AllWinner H3 DTS + add new I2C entries for AllWinner H3 DTS
Hi,
On Sat, Apr 16, 2016 at 1:11 AM, Martin Ayotte wrote:
> Hi everyone,
>
> This patch is submit to provide endusers access to additional UARTs on
> AllWinner H3 SoC along with I2C ports.
>
> Regards,
> Martin.
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 36 ++
> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 36 ++
> arch/arm/boot/dts/sun8i-h3.dtsi| 75
First of all, you are touching 3 different files here. These should
be separate patches.
Secondly, our policy is to not have a default function for generic GPIO pins.
Regards
ChenYu
> ++
> 3 files changed, 147 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> index f93f5d1..f0b9823 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> @@ -176,6 +176,42 @@
> status = "okay";
> };
>
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins_a>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins_a>;
> + status = "okay";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins_a>;
> + status = "okay";
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins_a>;
> + status = "okay";
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_a>;
> + status = "okay";
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pins_a>;
> + status = "okay";
> +};
> +
> &usb1_vbus_pin_a {
> allwinner,pins = "PG13";
> };
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> index daf50b9a6..6994349 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> @@ -161,6 +161,42 @@
> status = "okay";
> };
>
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins_a>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins_a>;
> + status = "okay";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins_a>;
> + status = "okay";
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins_a>;
> + status = "okay";
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_a>;
> + status = "okay";
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pins_a>;
> + status = "okay";
> +};
> +
> &usbphy {
> /* USB VBUS is always on */
> status = "okay";
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 4a4926b..c947360d 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -508,6 +508,48 @@
> allwinner,pull = ;
> };
>
> + uart1_pins_a: uart1@0 {
> + allwinner,pins = "PG6", "PG7";
> + allwinner,function = "uart1";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart2_pins_a: uart2@0 {
> + allwinner,pins = "PA0", "PA1";
> + allwinner,function = "uart2";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + uart3_pins_a: uart3@0 {
> + allwinner,pins = "PA13", "PA14";
> + allwinner,function = "uart3";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + i2c0_pins_a: i2c0@0 {
> + allwinner,pins = "PA11", "PA12";
> + allwinner,function = "i2c0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + i2c1_pins_a: i2c1@0 {
> + allwinner,pins = "PA18", "PA19";
> + allwinner,function = "i2c1";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + i2c2_pins_a: i2c2@0 {
> + allwinner,pins = "PE12", "PE13";
> + allwinner,function = "i2c2";
> + allwi
[linux-sunxi] Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
On 18/04/16 18:05, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 17:32:49 +0300
> Roger Quadros wrote:
>
>> Boris,
>>
>> On 30/03/16 19:14, Boris Brezillon wrote:
>>> Implementing the mtd_ooblayout_ops interface is the new way of exposing
>>> ECC/OOB layout to MTD users.
>>>
>>> Signed-off-by: Boris Brezillon
>>> ---
>>> drivers/mtd/nand/omap2.c | 194
>>> +++
>>> 1 file changed, 113 insertions(+), 81 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index 4ebf16b..bca154a 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -169,8 +169,6 @@ struct omap_nand_info {
>>> u_char *buf;
>>> int buf_len;
>>> struct gpmc_nand_regs reg;
>>> - /* generated at runtime depending on ECC algorithm and layout selected
>>> */
>>> - struct nand_ecclayout oobinfo;
>>> /* fields specific for BCHx_HW ECC scheme */
>>> struct device *elm_dev;
>>> struct device_node *of_node;
>>> @@ -1639,19 +1637,108 @@ static bool omap2_nand_ecc_check(struct
>>> omap_nand_info *info,
>>> return true;
>>> }
>>>
>>> +static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
>>> + struct mtd_oob_region *oobregion)
>>> +{
>>> + struct nand_chip *chip = mtd_to_nand(mtd);
>>> + int off = chip->options & NAND_BUSWIDTH_16 ?
>>> + BADBLOCK_MARKER_LENGTH : 1;
>>
>> IMO "off = 1" is valid only for OMAP_ECC_HAM1_CODE_HW and 8-bit NAND.
>> For all other layouts it is always set to BADBLOCK_MARKER_LENGTH.
>
> Indeed.
>
> [...]
>
>>> - /* all OOB bytes from oobfree->offset till end off OOB are free */
>>> - ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
>>> /* check if NAND device's OOB is enough to store ECC signatures */
>>> - if (mtd->oobsize < (ecclayout->eccbytes + BADBLOCK_MARKER_LENGTH)) {
>>> + min_oobbytes = (oobbytes_per_step *
>>> + (mtd->writesize / nand_chip->ecc.size)) +
>>> + (nand_chip->options & NAND_BUSWIDTH_16 ?
>>> + BADBLOCK_MARKER_LENGTH : 1);
>>
>> would it affect this as well?
>
> And here as well.
>
> I've generated a patch (see below) fixing those problems.
>
>>
>>> + if (mtd->oobsize < min_oobbytes) {
>>> dev_err(&info->pdev->dev,
>>> "not enough OOB bytes required = %d, available=%d\n",
>>> - ecclayout->eccbytes, mtd->oobsize);
>>> + min_oobbytes, mtd->oobsize);
>>> err = -EINVAL;
>>> goto return_error;
>>> }
>>>
>>
>> I will need to test this change with all possible configurations.
>> The number of configurations on OMAP is a bit overwhelming :(.
>
> Sorry about that, but at least now I have someone who can test it :).
>
> Thanks,
>
> Boris
>
> --->8---
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 9b96f56..07d4039 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1640,9 +1640,13 @@ static bool omap2_nand_ecc_check(struct omap_nand_info
> *info,
> static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
> struct mtd_oob_region *oobregion)
> {
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - int off = chip->options & NAND_BUSWIDTH_16 ?
> - BADBLOCK_MARKER_LENGTH : 1;
> + struct omap_nand_info *info = mtd_to_omap(mtd);
> + struct nand_chip *chip = &info->nand;
> + int off = BADBLOCK_MARKER_LENGTH;
> +
> + if (info->ecc_opt == OMAP_ECC_HAM1_CODE_HW &&
> + !(chip->options & NAND_BUSWIDTH_16))
> + off = 1;
>
> if (section)
> return -ERANGE;
> @@ -1656,9 +1660,13 @@ static int omap_ooblayout_ecc(struct mtd_info *mtd,
> int section,
> static int omap_ooblayout_free(struct mtd_info *mtd, int section,
> struct mtd_oob_region *oobregion)
> {
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - int off = chip->options & NAND_BUSWIDTH_16 ?
> - BADBLOCK_MARKER_LENGTH : 1;
> + struct omap_nand_info *info = mtd_to_omap(mtd);
> + struct nand_chip *chip = &info->nand;
> + int off = BADBLOCK_MARKER_LENGTH;
> +
> + if (info->ecc_opt == OMAP_ECC_HAM1_CODE_HW &&
> + !(chip->options & NAND_BUSWIDTH_16))
> + off = 1;
>
> if (section)
> return -ERANGE;
> @@ -1682,8 +1690,7 @@ static int omap_sw_ooblayout_ecc(struct mtd_info *mtd,
> int section,
>struct mtd_oob_region *oobregion)
> {
> struct nand_chip *chip = mtd_to_nand(mtd);
> - int off = chip->options & NAND_BUSWIDTH_16 ?
> - BADBLOCK_MARKER_LENGTH : 1;
> + int off = BADBLOCK_MARKER_LENGTH;
>
> if (section >= chip->ecc.steps)
>
[linux-sunxi] Re: [PATCH 1/2] clk: sunxi: add predivider handling for factors clock
On Sun, Apr 17, 2016 at 11:53:47AM +0800, Vishnu Patekar wrote:
> Both of these patches in series has to be applied at the same time.
> I think this is the reason, it fails.
hi Xiaolong, would you help do a check whether we apply the patches in correct
sequence for this case?
> On 17 Apr 2016 09:26, "kbuild test robot" wrote:
>
> > Hi Vishnu,
> >
> > [auto build test ERROR on clk/clk-next]
> > [also build test ERROR on v4.6-rc3 next-20160415]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help improving the system]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Vishnu-Patekar/sunxi-factors-clock-predivider-handling/20160417-025801
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> > clk-next
> > config: arm-sunxi_defconfig (attached as .config)
> > reproduce:
> > wget
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=arm
> >
> > Note: the
> > linux-review/Vishnu-Patekar/sunxi-factors-clock-predivider-handling/20160417-025801
> > HEAD 19bb5fc952754381d9f4f9b2e57a1fa09f467359 builds fine.
> > It only hurts bisectibility.
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/clk/sunxi/clk-sunxi.c: In function 'sun6i_get_ahb1_factors':
> > >> drivers/clk/sunxi/clk-sunxi.c:310:9: error: 'struct factors_request'
> > has no member named 'parent_index'
> > if (req->parent_index == SUN6I_AHB1_PARENT_PLL6) {
> > ^
> >drivers/clk/sunxi/clk-sunxi.c: In function 'sun6i_ahb1_recalc':
> >drivers/clk/sunxi/clk-sunxi.c:340:9: error: 'struct factors_request'
> > has no member named 'parent_index'
> > if (req->parent_index == SUN6I_AHB1_PARENT_PLL6)
> > ^
> >
> > vim +310 drivers/clk/sunxi/clk-sunxi.c
> >
> > a78bb355 Chen-Yu Tsai 2016-01-25 304 if (req->parent_rate && req->rate
> > > req->parent_rate)
> > a78bb355 Chen-Yu Tsai 2016-01-25 305 req->rate =
> > req->parent_rate;
> > a78bb355 Chen-Yu Tsai 2016-01-25 306
> > a78bb355 Chen-Yu Tsai 2016-01-25 307 div =
> > DIV_ROUND_UP(req->parent_rate, req->rate);
> > a78bb355 Chen-Yu Tsai 2016-01-25 308
> > a78bb355 Chen-Yu Tsai 2016-01-25 309 /* calculate pre-divider if parent
> > is pll6 */
> > a78bb355 Chen-Yu Tsai 2016-01-25 @310 if (req->parent_index ==
> > SUN6I_AHB1_PARENT_PLL6) {
> > a78bb355 Chen-Yu Tsai 2016-01-25 311 if (div < 4)
> > a78bb355 Chen-Yu Tsai 2016-01-25 312 calcp = 0;
> > a78bb355 Chen-Yu Tsai 2016-01-25 313 else if (div / 2 < 4)
> >
> > :: The code at line 310 was first introduced by commit
> > :: a78bb35552a800949b2bf68f372d3d6ccabdd790 clk: sunxi: rewrite
> > sun6i-a31-ahb1-clk using factors clk with custom recalc
> >
> > :: TO: Chen-Yu Tsai
> > :: CC: Maxime Ripard
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology
> > Center
> > https://lists.01.org/pipermail/kbuild-all Intel
> > Corporation
> >
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 08/19] ARM: sun5i: Add DRAM gates
On Wed, Mar 23, 2016 at 05:38:31PM +0100, Maxime Ripard wrote: > The DRAM gates control whether the image / display devices on the SoC have > access to the DRAM clock or not. > > Enable it. > > Signed-off-by: Maxime Ripard Applied, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v3 09/19] ARM: sun5i: Add TV encoder gate to the DTSI
On Wed, Mar 23, 2016 at 05:38:32PM +0100, Maxime Ripard wrote: > It turns out that the A13 / R8 also have a tve encoder block, and a gate > for it. > > Add it to the DT. > > Signed-off-by: Maxime Ripard > Acked-by: Chen-Yu Tsai Applied, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v3 06/19] ARM: sun5i: dt: Add pll3 and pll7 clocks
On Wed, Mar 23, 2016 at 05:38:29PM +0100, Maxime Ripard wrote: > Enable the pll3 and pll7 clocks in the DT that are used to drive the > display-related clocks. > > Signed-off-by: Maxime Ripard > Acked-by: Chen-Yu Tsai Applied, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v3 01/19] clk: composite: Add unregister function
Hi,
On Fri, Apr 15, 2016 at 03:28:56PM -0700, Stephen Boyd wrote:
> On 03/23, Maxime Ripard wrote:
> > The composite clock didn't have any unregistration function, which forced
> > us to use clk_unregister directly on it.
> >
> > While it was already not great from an API point of view, it also meant
> > that we were leaking the clk_composite structure allocated in
> > clk_register_composite.
> >
> > Add a clk_unregister_composite function to fix this.
> >
> > Signed-off-by: Maxime Ripard
> > ---
>
> I'm currently attempting to change the way clks are registered so
> that we don't return clk pointers from clk_register and have
> users add OF clk providers that return clk_hw pointers instead of
> clk pointers. Just a note, that this whole thing should be
> deleted in the next cycle if I can convert everything!
Ok.
>
> > drivers/clk/clk-composite.c | 15 +++
> > include/linux/clk-provider.h | 1 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> > index 1f903e1f86a2..b0f3b84ebd13 100644
> > --- a/drivers/clk/clk-composite.c
> > +++ b/drivers/clk/clk-composite.c
> > @@ -286,3 +286,18 @@ err:
> > kfree(composite);
> > return clk;
> > }
> > +
> > +void clk_unregister_composite(struct clk *clk)
> > +{
> > + struct clk_composite *composite;
> > + struct clk_hw *hw;
> > +
> > + hw = __clk_get_hw(clk);
> > + if (!hw)
> > + return;
> > +
> > + composite = to_clk_composite(hw);
> > +
> > + clk_unregister(clk);
> > + kfree(composite);
> > +}
>
> EXPORT_SYMBOL_GPL?
The register function is not registered, so I don't think that's
necessary.
> Do I need to pick this up?
I have a bunch of other clock patches that need this, so I guess it
would be easier if applied it directly with your acked-by, or if you
could apply it and give a stable branch I can base my future PR on.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH v3 03/19] clk: sunxi: Add PLL3 clock
On Fri, Apr 15, 2016 at 03:34:41PM -0700, Stephen Boyd wrote: > On 03/23, Maxime Ripard wrote: > > The A10 SoCs and relatives have a PLL controller to drive the PLL3 and > > PLL7, clocked from a 3MHz oscillator, that drives the display related > > clocks (GPU, display engine, TCON, etc.) > > > > Add a driver for it. > > > > Acked-by: Rob Herring > > Acked-by: Chen-Yu Tsai > > Signed-off-by: Maxime Ripard > > --- > > Acked-by: Stephen Boyd Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v3 05/19] dt-bindings: clk: sun5i: add DRAM gates compatible
On Fri, Apr 15, 2016 at 03:29:11PM -0700, Stephen Boyd wrote: > On 03/23, Maxime Ripard wrote: > > The Allwinner SoCs have a gate controller to gate the access to the DRAM > > clock to the some devices that need to access the DRAM directly (mostly > > display / image related IPs). > > > > Use a simple gates driver to support the one found in the A13 / R8 SoCs. > > > > Signed-off-by: Maxime Ripard > > Acked-by: Chen-Yu Tsai > > Acked-by: Rob Herring > > --- > > Acked-by: Stephen Boyd Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
