[linux-sunxi] Re: [PATCH v2 07/52] dt-bindings: bluetooth: broadcom: Fix clocks check
On Wed, Sep 1, 2021 at 11:19 AM Maxime Ripard wrote: > The original binding was mentioning that valid values for the clocks and > clock-names property were one or two clocks from extclk, txco and lpo, > with extclk being deprecated in favor of txco. > > However, the current binding lists a valid array as extclk, txco and > lpo, with either one or two items. > > While this looks similar, it actually enforces that all the device trees > use either ["extclk"], or ["extclk", "txco"]. That doesn't make much > sense, since the two clocks are said to be equivalent, with one > superseeding the other. > > lpo is also not a valid clock anymore, and would be as the third clock > of the list, while we could have only this clock in the previous binding > (and in DTs). > > Let's rework the clock clause to allow to have either: > > - extclk, and mark it a deprecated > - txco alone > - lpo alone > - txco, lpo > > While ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device > tree so it's not an issue in practice. > > Similarly, ["lpo", "txco"] is still considered invalid, but it's > generally considered as a best practice to fix the order of clocks. > > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Linus Walleij > Cc: net...@vger.kernel.org > Reviewed-by: Rob Herring > Signed-off-by: Maxime Ripard Looks good to me! Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdYGnCd8fkAPPTP6VHFXC9k-_BNGqTE4cvPORyXJ%3DrVWLA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 15/54] dt-bindings: iio: st: Remove wrong items length check
On Wed, Jul 21, 2021 at 4:05 PM Maxime Ripard wrote: > The original bindings was listing the length of the interrupts as either > 1 or 2, depending on the setup. This is also what is enforced by the top > level schema. > > However, that is further constrained with an if clause that require > exactly two interrupts, even though it might not make sense on those > devices or in some setups. > > Let's remove the clause entirely. > > Cc: Denis Ciocca > Cc: Jonathan Cameron > Cc: Lars-Peter Clausen > Cc: Linus Walleij > Cc: linux-...@vger.kernel.org > Signed-off-by: Maxime Ripard Oops this was too ambitious. Sorry about that. Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdaJG2ghPaafzfTrYYCGh_t6ScC-u3N3angHaw%2Bbw3G6BA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v3 05/21] pinctrl: sunxi: Add support for the Allwinner H616-R pin controller
On Mon, Jan 18, 2021 at 3:09 AM Andre Przywara wrote: > There are only two pins left now, used to connect to the PMIC via I2C. > > Signed-off-by: Andre Przywara > Acked-by: Maxime Ripard > Reviewed-by: Jernej Skrabec Patch applied to the pinctrl tree. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdbY4V8C-7KXWx700fauUOjyQk04ghKQhKoZ6nxO2FE2nw%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v3 04/21] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
On Mon, Jan 18, 2021 at 3:09 AM Andre Przywara wrote: > Port A is used for an internal connection to some analogue circuitry > which looks like an AC200 IP (as in the H6), though this is not > mentioned in the manual. > > Signed-off-by: Andre Przywara Patch applied to the pinctrl tree. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdbeVJkEuLx7gC-FANevOq2QTr7GaQVMF5So%3Dkg346ty9Q%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v3 03/21] dt-bindings: pinctrl: Add Allwinner H616 compatible strings
On Mon, Jan 18, 2021 at 3:09 AM Andre Przywara wrote: > A new SoC, a new compatible string. > Also we were too miserly with just allowing seven interrupt banks. > > Signed-off-by: Andre Przywara Patch applied to the pinctrl tree. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdZKmDjaz9Pg9s3P_ve68tNhumHHcUL0coT%2BdAnoct%2BFww%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions
On Sun, Jan 3, 2021 at 11:00 AM Samuel Holland wrote: > As there is an RSB controller in the H6 SoC, there should be some pin > configuration for it. While no such configuration is documented, the > "s_i2c" pins are suspiciously on the "alternate" function 3, with no > primary function 2 given. This suggests the primary function for these > pins is actually RSB, and that is indeed the case. > > Add the "s_rsb" pin functions so the RSB controller can be used. > > Signed-off-by: Samuel Holland This patch applied to the pinctrl tree. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdagu9Sj9AEcGQYrnAAxUJWZKGZ2zina4XWubQ7WXYU-0A%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions
On Sun, Jan 3, 2021 at 11:00 AM Samuel Holland wrote: > As there is an RSB controller in the H6 SoC, there should be some pin > configuration for it. While no such configuration is documented, the > "s_i2c" pins are suspiciously on the "alternate" function 3, with no > primary function 2 given. This suggests the primary function for these > pins is actually RSB, and that is indeed the case. > > Add the "s_rsb" pin functions so the RSB controller can be used. > > Signed-off-by: Samuel Holland Is it OK if I just apply this patch to the pinctrl tree? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdZbNUxizfV5Oo8F8b0bsjNcBF6JfP%3DufykNLeqErvU-ug%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
On Wed, Dec 2, 2020 at 4:52 PM Maxime Ripard wrote: > There's a bunch of issues with wrapped lines alignment reported by > checkpatch --patch. > > Once fixed, > Acked-by: Maxime Ripard Andre, if you resend just the two pinctrl patches with the collected ACKs I can apply them. No DT binding changes needed? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdb4NCXcBCv-%2BD2go7cNK_LLJsN2HAVicMPRnRhOLQb6DA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v6 00/13] Add support for PinePhone LCD panel
On Wed, Jul 1, 2020 at 6:30 PM Ondřej Jirman wrote: > On Wed, Jul 01, 2020 at 05:25:32PM +0200, Sam Ravnborg wrote: > > Hi Ondrej. > > > > On Wed, Jul 01, 2020 at 12:31:13PM +0200, Ondrej Jirman wrote: > > > This patchset adds support for the LCD panel of PinePhone. > > > > > > I've tested this on PinePhone 1.0 and 1.2. > > > > > > Please take a look. > > > > > > thank you and regards, > > > Ondrej Jirman > > > > > > Changes in v6: > > > - Fixed spacing in yaml > > > - Fixed wrong vccio->iovcc supply name in the bindings doc > > > - I noticed that the original driver uses a delay of 20ms in the init > > > function to achieve a combined total of 120ms required from post-reset > > > to display_on. I've added a similar delay to xbd599_init, so that > > > xbd599 panel also has the right timing. (patch 9) > > > - v5->v6 diff: https://megous.com/dl/tmp/v5-v6.patch > > > - Added review/ack tags > > > - Learned to run dt_binding_check by myself ;) > > The patch-set does not apply clean on top of drm-misc-next - due to > > vrefresh removal. > > Please re-spin. > > Sorry for that. Rebased and retested. Sam will you apply it? I was in the middle of applying and ran into the same issue :D Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdYf87RymMwUFL%3DnXNs3dFVveLt7u0X3haL%3DSN%2BN6%2BV_vQ%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 13/13] arm64: dts: sun50i-a64-pinephone: Add touchscreen support
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > Pinephone has a Goodix GT917S capacitive touchscreen controller on > I2C0 bus. Add support for it. > > Signed-off-by: Ondrej Jirman Acked-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkda2LnZ7UQkp_ZDEVCfxHVQ-VUE7NH0dEGNHYrUd1LcC0Q%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 12/13] arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > From: Icenowy Zheng > > PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for > display. > > Backlight levels curve was optimized by Martijn Braam using a > lux meter. > > Add its device nodes. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Martijn Braam > Signed-off-by: Ondrej Jirman Acked-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdaca%3D1gvYv5e2v3BzZSTE_1gab6nOt6DCrFm3QX64xy9Q%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 11/13] drm/panel: st7703: Assert reset prior to powering down the regulators
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > The reset pin is inverted, so if we don't assert reset, the actual gpio > will be high and may keep driving the IO port of the panel. > > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdab8pOgrssi91wmKSJC5v2gu7VoQKt1MWG0g5AkNxk%2B7w%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 10/13] drm/panel: st7703: Enter sleep after display off
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > The datasheet suggests to issue sleep in after display off > as a part of the panel's shutdown sequence. > > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdYHmZi%2BBCRs8xzCUqiCEK7RHynHWeptTtEzJ1WHToMRFg%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 09/13] drm/panel: st7703: Add support for Xingbangda XBD599
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel used in > PinePhone. Add support for it. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdZcMA_Y_eH8_TL09Z0_DADDcUy5s_S45UfrnoSKmNgtXw%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 08/13] drm/panel: st7703: Move generic part of init sequence to enable callback
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > Calling sleep out and display on is a controller specific part > of the initialization process. Move it out of the panel specific > initialization function to the enable callback. > > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdZAZauS19W7GTbhB4FgjrVtd2%2BRPx9cuLAac4s4vx234A%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 07/13] drm/panel: st7703: Move code specific to jh057n closer together
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > It's better than having it spread around the driver. > > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdZN2rEB9gSQiBiB5Fu8tUUt%3DDCfF3dpfOBTsUbCc7HUgw%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 06/13] drm/panel: st7703: Prepare for supporting multiple panels
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > Parametrize the driver so that it can support more panels based > on st7703 controller. > > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdbWUW4AaZf3ZTvabdQ3SwwwBcdwYFOaE1ou4rbtUAUOEw%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 05/13] drm/panel: st7703: Rename functions from jh057n prefix to st7703
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > This is done so that code that's not specific to a particular > jh057n panel is named after the controller. Functions specific > to the panel are kept named after the panel. > > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdYJbojy5JzSQ-gvQC6QqGOGCNDLz4UVmCFyw7cZ20ekBQ%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 04/13] drm/panel: rocktech-jh057n00900: Rename the driver to st7703
On Fri, Jun 26, 2020 at 2:56 AM Ondrej Jirman wrote: > This rename is done so that the driver matches the name of the > display controller and in preparation for adding support for more > panels to the driver. > > This is just a basic file rename, with no code changes. > > Signed-off-by: Ondrej Jirman This is the right thing to do. Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdbJqFHCGkLgMM3pzgE4kYL7wH2FyK0fpOf1Gva1xicxuA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v3 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
Hi Ondrej, I see you took over this driver submission from Icenowy. On Wed, May 13, 2020 at 11:24 PM Ondrej Jirman wrote: > From: Icenowy Zheng > > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by > Xingbangda, which is used on PinePhone final assembled phones. > > It is based on Sitronix ST7703 LCD controller. > > Add support for it. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Ondrej Jirman (...) > create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c Nice! > + /* > +* Init sequence was supplied by the panel vendor. > +*/ > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, > + 0xF1, 0x12, 0x83); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI, > + 0x33, 0x81, 0x05, 0xF9, 0x0E, 0x0E, 0x20, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x25, > + 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02, 0x4F, 0x11, > + 0x00, 0x00, 0x37); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT, > + 0x25, 0x22, 0x20, 0x03); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF, > + 0x10, 0x10, 0x05, 0x05, 0x03, 0xFF, 0x00, 0x00, > + 0x00, 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR, > + 0x73, 0x73, 0x50, 0x50, 0x00, 0xC0, 0x08, 0x70, > + 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETVDC, 0x4E); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPANEL, 0x0B); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETCYC, 0x80); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETDISP, 0xF0, 0x12, 0xF0); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETEQ, > + 0x00, 0x00, 0x0B, 0x0B, 0x10, 0x10, 0x00, 0x00, > + 0x00, 0x00, 0xFF, 0x00, 0xC0, 0x10); > + dsi_dcs_write_seq(dsi, 0xC6, 0x01, 0x00, 0xFF, 0xFF, 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER, > + 0x74, 0x00, 0x32, 0x32, 0x77, 0xF1, 0xFF, 0xFF, > + 0xCC, 0xCC, 0x77, 0x77); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP, 0x07, 0x07); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x2C, 0x2C); > + dsi_dcs_write_seq(dsi, 0xBF, 0x02, 0x11, 0x00); > + > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1, > + 0x82, 0x10, 0x06, 0x05, 0xA2, 0x0A, 0xA5, 0x12, > + 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38, > + 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00, > + 0x03, 0x00, 0x00, 0x00, 0x75, 0x75, 0x31, 0x88, > + 0x88, 0x88, 0x88, 0x88, 0x88, 0x13, 0x88, 0x64, > + 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > + 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2, > + 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88, > + 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13, > + 0x57, 0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88, > + 0x75, 0x88, 0x23, 0x14, 0x00, 0x00, 0x02, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0A, > + 0xA5, 0x00, 0x00, 0x00, 0x00); > + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA, > + 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, 0x35, > + 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, 0x12, > + 0x18, 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, > + 0x35, 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, > + 0x12, 0x18); > + msleep(20); This stuff is really hard or impossible to understand without the datasheet. In my previous review I wrote: It appears that the Himax HX8363 is using the same display controller if you look at the datasheet: http://www.datasheet-pdf.com/PDF/HX8369-A-Datasheet-Himax-729024 There you find an explanation to some of the commands. That means, try to get rid of as much of the magic bytes as you can and use proper #defines. I know it takes some work but the result is so much more useful and readable. Further I wrote: You should definately insert code to read the MTP bytes: 0xDA manufacturer 0xDB driver version 0xDC LCD module/driver And print these, se e.g. my newly added NT35510 driv
[linux-sunxi] Re: [PATCH v3 2/5] dt-bindings: panel: Add binding for Xingbangda XBD599 panel
On Wed, May 13, 2020 at 11:24 PM Ondrej Jirman wrote: > From: Icenowy Zheng > > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. It is based on > Sitronix ST7703 LCD controller. > > Add its device tree binding. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Ondrej Jirman Reviewed-by: Linus Walleij Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdbb0Y32EG%3DtEx208eUh_CJndvnQGQvAnF_mG29Hd9-2Jg%40mail.gmail.com.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: handle probe defferal
On Thu, Apr 2, 2020 at 11:09 AM Corentin Labbe wrote: > When checking the logs on my sun8i-a33-olinuxino I saw: > sun8i-a23-r-pinctrl 1f02c00.pinctrl: Reset controller missing > but this driver was working after. > This message is just here because the reset controller was still not probed. > So don't say anything if the return code say to wait. > > Signed-off-by: Corentin Labbe Patch applied with Maxime's ACK! Thanks, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdb_JztWo9XhWZw9einj2D1fgBiB%2Bup3ZUrCOf5S-dT3VQ%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v2 3/5] drm: panel: add Xingbangda XBD599 panel
So following up on this: We should state in the commit message that this driver is for all displays using the Sitronix ST770x display controllers. The driver should be named panel-sitronix-st770x.c. On Thu, Mar 19, 2020 at 3:08 PM Linus Walleij wrote: > > +/* Manufacturer specific Commands send via DSI */ > > +#define ST7703_CMD_ALL_PIXEL_OFF 0x22 > > +#define ST7703_CMD_ALL_PIXEL_ON 0x23 > > +#define ST7703_CMD_SETDISP 0xB2 > > +#define ST7703_CMD_SETRGBIF 0xB3 > > +#define ST7703_CMD_SETCYC 0xB4 > > +#define ST7703_CMD_SETBGP 0xB5 > > +#define ST7703_CMD_SETVCOM 0xB6 > > +#define ST7703_CMD_SETOTP 0xB7 > > +#define ST7703_CMD_SETPOWER_EXT 0xB8 > > +#define ST7703_CMD_SETEXTC 0xB9 > > +#define ST7703_CMD_SETMIPI 0xBA > > +#define ST7703_CMD_SETVDC 0xBC > > +#define ST7703_CMD_SETSCR 0xC0 > > +#define ST7703_CMD_SETPOWER 0xC1 > > +#define ST7703_CMD_UNK_C6 0xC6 > > +#define ST7703_CMD_SETPANEL 0xCC > > +#define ST7703_CMD_SETGAMMA 0xE0 > > +#define ST7703_CMD_SETEQ0xE3 > > +#define ST7703_CMD_SETGIP1 0xE9 > > +#define ST7703_CMD_SETGIP2 0xEA I should have seen the ST7703 prefix shouldn't I... > This actually looks very much like an Ilitek display controller. > Some commands are clearly identical to Ilitek ILI9342: > http://www.ampdisplay.com/documents/pdf/ILI9342_DS_V008_20100331.pdf I'm still wondering about the apparent similarity between ST770x and Ilitek ILI9342, haha :D > 1. Try to determine what the actual display controller > is. I think it is some Ilitek. OK so this is Sitronix ST770x. > 2. Write a panel-ilitek-ili9342.c (if that is the actual controller) > and parameterize it for this display controller the same > way we do in e.g. panel-novatek-nt35510.c or > panel-ilitek-ili9322.c, so you use the compatible string > to set up the actual per-display settings for this display > controller. This should be panel-sitronix-st770x.c Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdZnTf2jPrPV%2B%2B1HDk4tf2BK2NJnv5gkd-1Nc5KT3pu0NQ%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
On Fri, Mar 20, 2020 at 9:07 AM Icenowy Zheng wrote: > 于 2020年3月19日 GMT+08:00 下午10:14:27, Linus Walleij > 写到: > >On Mon, Mar 16, 2020 at 2:37 PM Icenowy Zheng wrote: > >As noticed in the review of the driver, this display is very close to > >himax,hx8363. > > > >I think the best is to determin what actual display controller it is, > >I think it is some kind of Ilitek controller since Ilitek ili9342 is > >clearly very similar. > > It's Sitronix ST7703, same as the Librem 5 panel. Heh, I wonder how it comes that it is so similar to Ilitek. I guess I will never understand how the silicon ecosystem works in asia (I did read a lot of Bunnie Huang's articles and hardware hacking book to try to understand...) This file should be named sitronix,st7703.yaml then. According to the code in the Librem 5: https://source.puri.sm/Librem5/linux-next/blob/imx8-current-librem5/drivers/gpu/drm/panel/panel-sitronix-st7701.c The actual name of the display is Techstar ts8550b. And the display controller is st7701, so maybe we should actually name it sitronix,st770x.yaml if there are some sub-variants of st770x? > >properties: > > compatible: > >items: > > - const: xingbangda,xbd599 > > - const: ilitek,ili9342 > > > >Possibly use oneOf and add support for the himax,hx8363 > >already while you're at it. This should at least be: compatible: items: - enum: - xingbangda,xbd599 - himax,hx8363 - techstar,ts8550b - enum: - sitronix,st7701 - sitronix,st7703 So panel nodes using this panel become compatible = "xingbangda,sbd599", "sitronix,st7703" etc. This way it is straight-forward for drivers to identify the panel vendor and display controller. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdbeLAyhhkx115zAV0tdC7KJ4T0UoQ2QeDwTVN%2Bbtxp%3DJw%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v2 2/5] dt-bindings: panel: add binding for Xingbangda XBD599 panel
Hi Icenowy, On Mon, Mar 16, 2020 at 2:37 PM Icenowy Zheng wrote: > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. > > Add its device tree binding. > > Signed-off-by: Icenowy Zheng (...) > +properties: > + compatible: > +const: xingbangda,xbd599 As noticed in the review of the driver, this display is very close to himax,hx8363. I think the best is to determin what actual display controller it is, I think it is some kind of Ilitek controller since Ilitek ili9342 is clearly very similar. The best would be something like name the bindings ilitek-ili9342.yaml and then: properties: compatible: items: - const: xingbangda,xbd599 - const: ilitek,ili9342 Possibly use oneOf and add support for the himax,hx8363 already while you're at it. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdaVrfd1p%2BWyACy-gq-3BPsXJ_CZwi2OZe%2B%3DcsseBcvcaA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v2 3/5] drm: panel: add Xingbangda XBD599 panel
GP, 0x07, 0x07);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM, 0x2C, 0x2C);
> + dsi_dcs_write_seq(dsi, 0xBF, 0x02, 0x11, 0x00);
> +
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP1,
> + 0x82, 0x10, 0x06, 0x05, 0xA2, 0x0A, 0xA5, 0x12,
> + 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38,
> + 0x0C, 0x00, 0x03, 0x00, 0x00, 0x00, 0x0C, 0x00,
> + 0x03, 0x00, 0x00, 0x00, 0x75, 0x75, 0x31, 0x88,
> + 0x88, 0x88, 0x88, 0x88, 0x88, 0x13, 0x88, 0x64,
> + 0x64, 0x20, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88,
> + 0x02, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGIP2,
> + 0x02, 0x21, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x02, 0x46, 0x02, 0x88,
> + 0x88, 0x88, 0x88, 0x88, 0x88, 0x64, 0x88, 0x13,
> + 0x57, 0x13, 0x88, 0x88, 0x88, 0x88, 0x88, 0x88,
> + 0x75, 0x88, 0x23, 0x14, 0x00, 0x00, 0x02, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0A,
> + 0xA5, 0x00, 0x00, 0x00, 0x00);
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETGAMMA,
> + 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41, 0x35,
> + 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12, 0x12,
> + 0x18, 0x00, 0x09, 0x0D, 0x23, 0x27, 0x3C, 0x41,
> + 0x35, 0x07, 0x0D, 0x0E, 0x12, 0x13, 0x10, 0x12,
> + 0x12, 0x18);
Already just using the HX8363 datasheet you can turn this into
something much more readable akin to how the NT35510 driver
is done.
> +static const struct drm_display_mode xbd599_default_mode = {
> + .hdisplay= 720,
> + .hsync_start = 720 + 40,
> + .hsync_end = 720 + 40 + 40,
> + .htotal = 720 + 40 + 40 + 40,
> + .vdisplay= 1440,
> + .vsync_start = 1440 + 18,
> + .vsync_end = 1440 + 18 + 10,
> + .vtotal = 1440 + 18 + 10 + 17,
> + .vrefresh= 60,
I think this vrefresh is going away soon.
> + .clock = 69000,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> +
> + .width_mm= 68,
> + .height_mm = 136,
> + .type= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
All of this as well as some of the initialization
sequences should be per-variant data. (Switched by
the compatible).
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CACRpkdahrHmXWpdqoApFEq6cW2gatMfds9SMZGwsUnNHt%2BJ0aQ%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 2/2] pinctrl: sunxi: Mask non-wakeup IRQs on suspend
On Fri, Jan 17, 2020 at 10:33 PM Samuel Holland wrote: > The pin controller hardware does not distinguish IRQs intended for > wakeup from other IRQs, so we must mask non-wakeup IRQs in software to > prevent inadvertent wakeups. This is accomplished at the irqchip level > via the IRQCHIP_MASK_ON_SUSPEND flag. > > Signed-off-by: Samuel Holland Patch applied. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdajokCMpJ98yfFp-s23jG96wO_N9R2ZXvXB%2BhU6XMs%3Dng%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 1/2] pinctrl: sunxi: Forward calls to irq_set_irq_wake
On Fri, Jan 17, 2020 at 10:33 PM Samuel Holland wrote: > The pinctrl irqchip may be connected to an irqchip that implements the > .irq_set_wake callback, such as the R_INTC on A31 and newer sunxi SoCs. > In order for GPIOs to be able to trigger wakeup, the IRQ from the > pinctrl to the upper irqchip must also be enabled for wakeup. Since the > kernel's IRQ core already manages the "wake_depth" of each IRQ, no > additional accounting is needed in the pinctrl driver. > > Signed-off-by: Samuel Holland Patch applied with Maxime's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdYtmRWai8X4yAxNt57zT2eUyLdkDaYCmB%3D0BU62zAa81g%40mail.gmail.com.
[linux-sunxi] Re: [PATCH] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR
On Sun, Aug 25, 2019 at 5:06 PM Alejandro González wrote: > Jernej Skrabec compared the BSP driver with this > driver, and found that the BSP driver configures pinctrl to operate at > 1.8 V when entering DDR mode (although 3.3 V operation is supported), while > the mainline kernel lacks any mechanism to switch voltages dynamically. (...) > the kernel lacks the required > dynamic pinctrl control for now This is not a pin control thing, the I/O voltage level is usually controlled by a regulator called VCCQ, if the selection of the voltage rails is inside the pin control registers, see the solution in drivers/pinctrl/sh-pfc/pfc-sh73a0.c where we simply provide a regulator from inside the pinctrl driver to make things easy for the MMC core. Do this thing! If you don't have time to fix it up properly right now I would slap in a big FIXME in the code so people know this needs to be fixed properly. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdazfe3gJr6Q%2BX05GzxPuKtUg0M780SPA_oR5bd%2B-xBPvA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v5 1/6] pinctrl: sunxi: v3s: introduce support for V3
On Sun, Jul 28, 2019 at 5:13 AM Icenowy Zheng wrote: > Introduce the GPIO pins that is only available on V3 (not on V3s) to the > V3s pinctrl driver. > > Signed-off-by: Icenowy Zheng > Acked-by: Maxime Ripard Patch applied to the pinctrl tree. Ypurs, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdY65Ob-zbd%2Bc4reUzYtXdk441horQ0ykL08YeBrgXWqQw%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v3 1/9] pinctrl: sunxi: v3s: introduce support for V3
On Mon, Jun 24, 2019 at 2:40 PM Maxime Ripard wrote: > On Sun, Jun 23, 2019 at 12:37:53PM +0800, Icenowy Zheng wrote: > > Introduce the GPIO pins that is only available on V3 (not on V3s) to the > > V3s pinctrl driver. > > > > Signed-off-by: Icenowy Zheng > > --- > > Changes in v3: > > - Fixed code alignment. > > - Fixed LVDS function number. > > - SUNXI_FUNCTION(0x2, "uart2"), /* TX */ > > - SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PB_EINT0 */ > > + SUNXI_FUNCTION(0x2, "uart2"), /* TX */ > > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PB_EINT0 */ > > I'm not sure why all that churn is needed. > > Looks good otherwise. Should I apply the patch or wait for a new version without the whitespace fixes? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdaQSg4qWWF1XurWA8wnW%2BezGtTympVT9DvkF87VKEQVzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 5/9] dt-bindings: vendor-prefixes: add SoChip
On Sun, Jun 23, 2019 at 6:39 AM Icenowy Zheng wrote: > Shenzhen SoChip Technology Co., Ltd. is a hardware vendor that produces > EVBs with Allwinner chips. There's also a SoC named S3 that is developed > by Allwinner (based on Allwinner V3/V3s) but branded SoChip. > > Add the vendor prefix for SoChip. > > Signed-off-by: Icenowy Zheng > Reviewed-by: Rob Herring > --- > No changes in v3. > > Changes in v2: > - Add the review tag by Rob. Should I apply this to the pinctrl tree? Rob? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdbbxgeGPh1oKfyKKOMhpXiz4sQWjZv23FbYaafCz6NyCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 00/11] Support for Allwinner V3/S3L and Sochip S3
On Tue, Jun 11, 2019 at 4:10 PM Icenowy Zheng wrote: > dt-bindings: pinctrl: add missing compatible string for V3s > dt-bindings: pinctrl: add compatible string for Allwinner V3 pinctrl I applied these two so we get down the depth of the patch stack. Waiting for a v3 on the pinctrl patch. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdbSo%3DoKh94GxmLX_FrhCuoZJyY27WeV8KJjBW6gTUrh%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 02/11] dt-bindings: pinctrl: add compatible string for Allwinner V3 pinctrl
On Tue, Jun 11, 2019 at 4:11 PM Icenowy Zheng wrote: > The Allwinner V3 SoC, despite come with the same die with V3s, has more > GPIO pins than V3s, and a different compatible string for pinctrl is > needed. > > Add the compatible string for V3 pinctrl. > > Signed-off-by: Icenowy Zheng > Reviewed-by: Rob Herring > --- > Changes in v2: > - Add the review tag by Rob. Patch applied. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdav8F0F%3DKepa6YskZbFEC6vfGxRe89VpK%2Bbw8o_%2BdgAdQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 01/11] dt-bindings: pinctrl: add missing compatible string for V3s
On Tue, Jun 11, 2019 at 4:10 PM Icenowy Zheng wrote: > The pinctrl driver of V3s is already available and used in the kernel, > but the compatible string of it is forgotten to be added. > > Add the missing compatible string. > > Signed-off-by: Icenowy Zheng > Acked-by: Maxime Ripard > Reviewed-by: Rob Herring > --- > Changes in v2: > - Add the ACK tag by Maxime and the review tag by Rob. Patch applied to the pinctrl tree. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CACRpkdaj-VkHaENpSqW32gFYBuLDErzqoKZ-aD4W4htORN_SiA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 4/9] pinctrl: sunxi: Support I/O bias voltage setting on H6
On Sat, Apr 13, 2019 at 6:54 PM wrote:
> From: Ondrej Jirman
>
> H6 SoC has a "pio group withstand voltage mode" register (datasheet
> description), that needs to be used to select either 1.8V or 3.3V I/O mode,
> based on what voltage is powering the respective pin banks and is thus used
> for I/O signals.
>
> Add support for configuring this register according to the voltage of the
> pin bank regulator (if enabled).
>
> This is similar to the support for I/O bias voltage setting patch for A80
> and the same concerns apply. See:
>
> commit 402bfb3c1352 ("Support I/O bias voltage setting on A80")
>
> Signed-off-by: Ondrej Jirman
> Acked-by: Maxime Ripard
This patch applied to the pinctrl tree for v5.2.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 3/9] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
On Sat, Apr 13, 2019 at 6:54 PM 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 > Acked-by: Maxime Ripard This patch applied to the pinctrl tree for v5.2. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Tue, Apr 9, 2019 at 1:22 AM Ondřej Jirman wrote: > > > +enable-active-high; > > > +gpio = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */ > > > > Is enable-active-high still needed? It's redundant with the > > GPIO_ACTIVE_HIGH flag. > > Looking at the code, use/non-use of enable-active-high inhibits > flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag > is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would > ignore it too and print a warning). > > So enable-active-high is still necessary here. > > See comment in gpiolib-of.c where this is handled: > > /* > * The regulator GPIO handles are specified such that the > * presence or absence of "enable-active-high" solely controls > * the polarity of the GPIO line. Any phandle flags must > * be actively ignored. > */ Yeah this caused me special headache in the current merge window because of buggy code on my part. This is an effect of this flag being defined for powerpc ages before we properly implemented generic GPIO bindings. We just have to respect it. See: https://marc.info/?l=linux-gpio=155417774822532=2 Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 09/12] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
On Sat, Apr 6, 2019 at 1:45 AM 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 > --- > drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +- > drivers/pinctrl/sunxi/pinctrl-sunxi.c | 38 --- > drivers/pinctrl/sunxi/pinctrl-sunxi.h | 4 ++- I need Maxime's ACK on these patches to merge. Can the pinctrl parts be applied independently of the rest of the changes when Maxime is happy with the patches? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 00/14] Support for Allwinner V3/S3L and Sochip S3
On Tue, Mar 12, 2019 at 10:24 PM Icenowy Zheng wrote: > This patchset tries to add support for Allwinner V3/S3L and Sochip S3. I see there is some review comments on this patch set so I am waiting for v2. When we have something Maxime, Rob etc has ACKed, I suggest I merge the pinctrl stuff into an immutable branch in the pinctrl tree so that it can be pulled in to ARM SoC if need be (for DTS files to compile for example). Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/9] pinctrl: sunxi: Support I/O bias voltage setting on A80
On Wed, Feb 6, 2019 at 4:32 AM Chen-Yu Tsai wrote: > The A80 SoC has configuration registers for I/O bias voltage. Incorrect > settings would make the affected peripherals inoperable in some cases, > such as Ethernet RGMII signals biased at 2.5V with the settings still > at 3.3V. However low speed signals such as MDIO on the same group of > pins seem to be unaffected. > > Previously there was no way to know what the actual voltage used was, > short of hard-coding a value in the device tree. With the new pin bank > regulator supply support in place, the driver can now query the > regulator for its voltage, and if it's valid (as opposed to being the > dummy regulator), set the bias voltage setting accordingly. > > Add a quirk to denote the presence of the configuration registers, and > a function to set the correct setting based on the voltage read back > from the regulator. > > This is only done when the regulator is first acquired and enabled. > While it would be nice to have a notifier on the regulator so that when > the voltage changes, the driver can update the setting, in practice no > board currently supports dynamic changing of the I/O voltages. > > Signed-off-by: Chen-Yu Tsai I merged the v5.0-rc6 into my devel branch and applied this patch on top now. All the DTS file changes should be merged through ARM SoC, and they should work fine now. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/9] pinctrl: sunxi: Support I/O bias voltage setting on A80
On Wed, Feb 6, 2019 at 4:32 AM Chen-Yu Tsai wrote: > The A80 SoC has configuration registers for I/O bias voltage. Incorrect > settings would make the affected peripherals inoperable in some cases, > such as Ethernet RGMII signals biased at 2.5V with the settings still > at 3.3V. However low speed signals such as MDIO on the same group of > pins seem to be unaffected. > > Previously there was no way to know what the actual voltage used was, > short of hard-coding a value in the device tree. With the new pin bank > regulator supply support in place, the driver can now query the > regulator for its voltage, and if it's valid (as opposed to being the > dummy regulator), set the bias voltage setting accordingly. > > Add a quirk to denote the presence of the configuration registers, and > a function to set the correct setting based on the voltage read back > from the regulator. > > This is only done when the regulator is first acquired and enabled. > While it would be nice to have a notifier on the regulator so that when > the voltage changes, the driver can update the setting, in practice no > board currently supports dynamic changing of the I/O voltages. > > Signed-off-by: Chen-Yu Tsai Hi Chen-Yu, thanks for the patch! I tried to apply it on the pinctrl devel branch (for v5.1) but it failed to apply, I assume because it depends on the fixes that I just sent to Torvalds. Shall we proceed like this that I merge v5.0-rc6 as soon as it is out and then try to apply this on top of that instead, so we get rid of this conflict? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: a83t: Fix IRQ offset typo for PH11
On Tue, Dec 4, 2018 at 10:05 AM Chen-Yu Tsai wrote:
> Pin PH11 is used on various A83T board to detect a change in the OTG
> port's ID pin, as in when an OTG host cable is plugged in.
>
> The incorrect offset meant the gpiochip/irqchip was activating the wrong
> pin for interrupts.
>
> Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller
> support")
> Cc:
> Signed-off-by: Chen-Yu Tsai
Patch applied for fixes with Maxime's ACK.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 0/2] pinctrl: sunxi: a64: Drop numeral from csi0/ts0
On Mon, Dec 3, 2018 at 4:41 PM Chen-Yu Tsai wrote: > This small series renames the csi0 and ts0 pin function names to csi and > ts. This makes the names match the datasheet. As there are only one of > each type of controller, having a numeral suffix doesn't make sense. > > I'd like to do the rename now while we don't have users nor support for > these two controllers. I planned to send this together with CSI support > for the A64, but Jagan beat me to it, so here it is. Patch applied with Maxime's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH v4 11/17] pinctrl: sunxi: add support for suniv F1C100s (newer F-series SoCs)
On Sun, Nov 25, 2018 at 8:44 AM Mesih Kilinc wrote: > The suniv F1C100s chip (several new F-series SoCs) of Allwinner has a > pin > controller like other SoCs from Allwinner. > > Add support for it. > > Signed-off-by: Mesih Kilinc > Acked-by: Maxime Ripard Patch applied to the pin control tree for v4.21. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH v4 10/17] dt-bindings: pinctrl: Add Allwinner suniv F1C100s pinctrl
On Sun, Nov 25, 2018 at 8:44 AM Mesih Kilinc wrote: > Add compatible string for Allwinner suniv F1C100s SoC's pinctrl. > > Signed-off-by: Mesih Kilinc > Acked-by: Maxime Ripard Patch applied to the pin control tree for v4.21. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 3/7] pinctrl: sunxi: add support for H6 R_PIO pin controller
On Thu, May 3, 2018 at 8:38 PM, Icenowy Zheng <icen...@aosc.io> wrote: > Allwinner H6 SoC has a R_PIO pin controller like other Allwinner SoCs, > which controls the PL and PM pin banks. > > Add support for it. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> Patch applied with the ACKs. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/9] Initial Allwinner H6 support
On Fri, Mar 16, 2018 at 3:02 PM, Icenowy Zheng <icen...@aosc.io> wrote: > This patchset adds initial support for the Allwinner H6 SoC. > > It's quite different from earlier Allwinner SoCs. For example, the > memory map is refactored, and the CCU is rearranged. It's also the first > Allwinner SoC with PCI Express interface (although the implementation > of the PCI Express controller is broken), and the second one with USB > 3.0 (the first one is A80). > > This patchset adds the most basical support for it, including the main pin > controller, the main CCU and the basical device tree. > > Icenowy Zheng (9): > pinctrl: sunxi: refactor irq related register function to have desc > pinctrl: sunxi: introduce IRQ bank conversion function > pinctrl: sunxi: change irq_bank_base to irq_bank_map > pinctrl: sunxi: add support for the Allwinner H6 main pin controller I applied these pinctrl patches for v4.17 so anything dependent on that can now be merged. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 4/9] pinctrl: sunxi: add support for the Allwinner H6 main pin controller
On Fri, Mar 16, 2018 at 3:02 PM, Icenowy Zheng <icen...@aosc.io> wrote: > The Allwinner H6 SoC has two pin controllers, one main controller > (called CPUX-PORT in user manual) and one controller in CPUs power > domain (called CPUS-PORT in user manual). > > This commit introduces support for the main pin controller on H6. > > The pin bank A and B are not wired out and hidden from the SoC's > documents, however it's shown that the "ATE" (an AC200 chip > co-packaged with the H6 die) is connected to the main SoC die via these > pin banks. The information about these banks is just copied from the BSP > pinctrl driver, but re-formatted to fit the mainline pinctrl driver > format. The GPIO functions are dropped, as they're impossible to use -- > except a GPIO only pin (PB20) which might be the IRQ of ATE. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > Acked-by: Rob Herring <r...@kernel.org> Patch applied with all the ACKs. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 3/9] pinctrl: sunxi: change irq_bank_base to irq_bank_map
On Fri, Mar 16, 2018 at 3:02 PM, Icenowy Zheng <icen...@aosc.io> wrote: > The Allwinner H6 SoC have its pin controllers with the first IRQ-capable > GPIO bank at IRQ bank 1 and the second bank at IRQ bank 5. > > Change the current code that uses IRQ bank base to a IRQ bank map, in > order to support the case that holes exist among IRQ banks. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > --- > Extracted in v4. Patch applied with Maxime's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 2/9] pinctrl: sunxi: introduce IRQ bank conversion function
On Fri, Mar 16, 2018 at 3:02 PM, Icenowy Zheng <icen...@aosc.io> wrote: > The Allwinner H6 SoC have its pin controllers with the first IRQ-capable > GPIO bank at IRQ bank 1 and the second bank at IRQ bank 5. Some > refactors in the sunxi pinctrl framework are needed. > > This commit introduces a IRQ bank conversion function, which replaces > the "(bank_base + bank)" code in IRQ register access. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > --- > Extracted in v4. Patch applied with Maxime's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 1/9] pinctrl: sunxi: refactor irq related register function to have desc
On Fri, Mar 16, 2018 at 3:02 PM, Icenowy Zheng <icen...@aosc.io> wrote: > As the new H6 SoC has holes in the IRQ registers, refactor the IRQ > related register function for getting the full pinctrl desc structure. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > --- > Changes in v4: > - Adjusted parameter sequence. Patch applied with Maxime's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2] pinctrl: sunxi: always look for apb block
On Sat, Mar 3, 2018 at 1:25 PM, Andre Przywara <andre.przyw...@arm.com> wrote: > The Allwinner pinctrl device tree binding suggests that a clock named > "apb" would drive the pin controller IP. However (for legacy reasons) we > rely on this clock actually being the first clock defined. > Since named clocks can be in any order, let's explicitly check for a > clock called "apb" if there is more than one clock referenced. > > Kudo to Maxime for suggesting this much more elegant approach. > > Signed-off-by: Andre Przywara <andre.przyw...@arm.com> Patch applied with Maxime's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 0/7] Initial Allwinner H6 support
On Fri, Feb 23, 2018 at 1:25 PM, Icenowy Zheng <icen...@aosc.io> wrote: > This patchset adds initial support for the Allwinner H6 SoC. > > It's quite different from earlier Allwinner SoCs. For example, the > memory map is refactored, and the CCU is rearranged. It's also the first > Allwinner SoC with PCI Express interface, and the second one with USB > 3.0 (the first one is A80). > > This patchset adds the most basical support for it, including the main pin > controller, the main CCU and the basical device tree. It seems the pin control part is more or less finished, I will apply it after v4 if Maxime provides ACKs for it. Is it fine to merge the pinctrl drivers/* portions in isolation from the rest? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 0/6] Initial Allwinner H6 support
On Sat, Feb 3, 2018 at 4:49 PM, Icenowy Zheng <icen...@aosc.io> wrote: > This patchset adds initial support for the Allwinner H6 SoC. I see there are still a few comments from Maxime and André so I'm waiting for a new patch set. I need their ACKs to proceed. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.
On Mon, Jan 29, 2018 at 9:25 AM, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote:
>> > +void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
>> > +{
>> > + struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
>> > + /* transform physical address to bus address */
>> > + dma_addr_t bus_addr = addr - PHYS_OFFSET;
>>
>> I am sorry if this is an unjustified drive-by comment. Maybe you
>> have already investigate other ways to do this.
>
> It's definitely not unjustified :)
>
>> Accessing PHYS_OFFSET directly seems unintuitive and not good
>> practice.
>>
>> But normally an dma_addr_t only comes from some function inside
>> such as: dma_alloc_coherent() for a contigous
>> buffer which is coherent in physical memory, or from some buffer <=
>> 64KB that is switching ownership between device and CPU explicitly
>> with dma_map* or so. Did you check with Documentation/DMA-API.txt?
>
> So, I've discussed this with Arnd a month ago or so, because I'm not
> really fond of the current approach but we haven't found better way to
> do it yet.
>
> The issue is that all the DMA accesses are done not through the main
> AXI bus, but through a separate bus dedicated for memory accesses,
> where the RAM is mapped at the address 0. So the CPU and DMA devices
> have a different mapping for the RAM.
Aha, I see the problem ... but since the dma_addr_t is supposed
to actually be the address the DMA controller sees, something is
apparently broken.
> I guess we could address this by using the field dma_pfn_offset that
> seems to be used in similar situations.
That does seem like the right thing to do (to me).
> However, in DT systems, that
> field is filled only with the parent's node dma-ranges property. In
> our case, and since the DT parenthood is based on the "control" bus,
> and not the "data" bus, our parent node would be the AXI bus, and not
> the memory bus that enforce those constraints.
>
> And other devices doing DMA through regular DMA accesses won't have
> that mapping, so we definitely shouldn't enforce it for all the
> devices there, but only the one connected to the separate memory bus.
>
> tl; dr: the DT is not really an option to store that info.
>
> I suggested setting dma_pfn_offset at probe, but Arnd didn't seem too
> fond of that approach either at the time.
>
> So, well, I guess we could do better. We just have no idea how :)
Usually of Arnd cannot suggest something smart, neither can I :(
If some aspect of the memory layout of the system *really* doesn't
fit into DT because of the assumptions that DT is doing about
how systems work, we have a problem.
Is the problem that DT's model assumes that devices have one and
only one data port to the system memory, and that is how it
populates the Linux devices?
I guess, if nothing else works, I would use auxdata in the board file.
It is our definitive last resort when DT doesn't hold.
I.e. I would go into struct of_dev_auxdata
(from ) and add a
dma_pfn_offset field that gets set into the device's dma_pfn_offset
in drivers/of/platform.c overriding anything else and use that to hammer
it down in the boardfile.
But I bet some DT people are going to have other ideas.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.
On Tue, Jan 23, 2018 at 9:18 AM, Yong Deng <yong.d...@magewell.com> wrote:
> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> interface and CSI1 is used for parallel interface. This is not
> documented in datasheet but by test and guess.
>
> This patch implement a v4l2 framework driver for it.
>
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
>
> Tested-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> Signed-off-by: Yong Deng <yong.d...@magewell.com>
This is cool stuff :)
> +void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
> +{
> + struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
> + /* transform physical address to bus address */
> + dma_addr_t bus_addr = addr - PHYS_OFFSET;
I am sorry if this is an unjustified drive-by comment. Maybe you
have already investigate other ways to do this.
Accessing PHYS_OFFSET directly seems unintuitive
and not good practice.
But normally an dma_addr_t only comes from some
function inside such as:
dma_alloc_coherent() for a contigous buffer which is coherent
in physical memory, or from some buffer <= 64KB that
is switching ownership between device and CPU explicitly
with dma_map* or so. Did you check with
Documentation/DMA-API.txt?
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 0/7] Initial Allwinner H6 support
On Sat, Jan 6, 2018 at 5:18 AM, Icenowy Zheng <icen...@aosc.io> wrote: > This patchset adds initial support for the Allwinner H6 SoC. Can I apply the pin control patches without the clock patches? Also waiting for Maxime and/or Chen-Yu to provide some review before merging this. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: fix a typo when merging A20 support to A10 driver
On Thu, Dec 28, 2017 at 2:20 PM, Icenowy Zheng <icen...@aosc.io> wrote:
> When merging A20 pinctrl support to A10 pinctrl driver, the I2C function
> of PI3 is wrongly written as "i2c3" (it should be "i2c4").
>
> Fix this typo.
>
> Fixes: cad4e209c102 ("pinctrl: sunxi: add support of R40 to A10 pinctrl
> driver")
> Reported-by: Mark Kettenis <mark.kette...@xs4all.nl>
> Signed-off-by: Icenowy Zheng <icen...@aosc.io>
Patch applied.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: axp209: add missing Kconfig dependencies
On Thu, Dec 14, 2017 at 10:43 AM, Quentin Schulz
<quentin.sch...@free-electrons.com> wrote:
> This fixes some compilation issues.
>
> GENERIC_PINCONF and OF at least for pinconf_generic_dt_*, PINMUX at
> least for pinmux_ops and GPIOLIB for at least gpio_chip.
>
> Fixes: 23f75d7dfa92 ("pinctrl: axp209: add pinctrl features")
>
> Reported-by: Randy Dunlab <rdun...@infradead.org>
Fixed that name.
> Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com>
Patch applied with Randy's ACK.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: axp209: dereference pointer after it's been set
On Wed, Dec 13, 2017 at 9:55 AM, Quentin Schulz
<quentin.sch...@free-electrons.com> wrote:
> The number of GPIOs is gotten from a field within the structure
> referenced in the of_device.data but it was actually read before it was
> retrieved, thus it was dereferencing a null pointer.
>
> Set the number of GPIOs after retrieving of_device.data.
>
> Fixes: e1190083b89b ("pinctrl: axp209: add support for AXP813 GPIOs")
>
> Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com>
> Reported-by: Mylène Josserand <mylene.josser...@free-electrons.com>
Patch applied with the tags for test and ACK.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 8/9] pinctrl: axp209: add support for AXP813 GPIOs
On Fri, Dec 8, 2017 at 2:41 PM, Quentin Schulz <quentin.sch...@free-electrons.com> wrote: >> - pctl->desc = _data; >> + pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev); >> pctl->regmap = axp20x->regmap; >> pctl->dev = >dev; >> > > I am using pctl->desc before retrieving it, thus dereferencing from a > null pointer. > > We just have to move > pctl->chip.ngpio= pctl->desc->npins; > after > pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev); > > Linus, I guess that I should send a patch to fix this or is there an > other way not to have to apply such a small and dumb patch? Just send a patch based on my pin control tree "devel" branch or linux-next, it's cool. Things like this happens all the time. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
On Wed, Dec 6, 2017 at 1:55 AM, André Przywara <andre.przyw...@arm.com> wrote: > On 01/12/17 09:56, Linus Walleij wrote: >> It is a valid cause. Just >> has to be weighed with other stuff, like maintainability, debuggability, >> maintainers viewpoint. ... > > So to keep Maxime happy I actually designed this "driver" more like a > shim: to generate the table the current driver expects from the DT, and > actually not touching the existing driver at all. > So maintainability should actually be less of a concern: the driver will > just work with whatever one throws at it from the DT side, without > requiring frequent changes or additions. > In the moment we still need to write, review and merge *data* files for > each new SoC. And as I mentioned before, Allwinner decided to push for > new, slightly different chips every few months, so there will be more to > come. With at least the pinctrl driver out of the way we have one > problem less to worry about. I think you need mainly to convince Maxime that this is something that he wants to maintain, going forward. I am as subsystem maintainer pretty pleased as long as standard properties etc are used to encode the data into the devicetree, and DT maintrainers are not actively vetoing what you do. If it leads to a conflict between Allwinner maintainers it is not worth the effort for reasons that are social rather than technical. To me it is a very nice but as with all volunteer communities also very vulnerable endavour. Please make sure not to push your point so hard that it hurts your our your colleagues feelings. I know people are passionate about their ideas, which is usally good but also scare me sometimes because they sometimes become so passionate that it makes them bad team players. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/2] pinctrl: sunxi: Disable strict mode for H5 driver
On Thu, Nov 30, 2017 at 5:07 PM, Andre Przywara <andre.przyw...@arm.com> wrote: > On 30/11/17 15:51, Linus Walleij wrote: >> On Sat, Nov 25, 2017 at 1:02 PM, Andre Przywara <andre.przyw...@arm.com> >> wrote: >> >>> All of the H5 boards in the kernel reference the MMC0 CD pin twice in >>> their DT, so strict mode will make the MMC driver fail to load. >>> To keep existing DTs working, disable strict mode in the H5 driver. >>> >>> Signed-off-by: Andre Przywara <andre.przyw...@arm.com> >>> Reported-by: Chris Obbard <obba...@gmail.com> >> >> Patch applied with Maxime's ACK. > > Thanks for that (also to Maxime and Chen-Yu) and the smooth handling! > > Sorry, I just see that I didn't point this out explicitly, but this is > to fix a regression introduced in 4.15-rc1, so is this on a branch that > will be pushed for 4.15-rc, still? (Couldn't find anything quickly on > kernel.org) Should be upstream as: commit 07c43a382d7de3db01cc28bf2e17ed151cde2046 Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 00/11] add pinmuxing support for pins in AXP209 and AXP813 PMICs
On Tue, Dec 5, 2017 at 3:46 PM, Quentin Schulz <quentin.sch...@free-electrons.com> wrote: > The AXP209 and AXP813 PMICs have several pins (respectively 3 and 2) that can > be used either as GPIOs or for other purposes (ADC or LDO here). > > We already have a GPIO driver for the GPIO use of those pins on the AXP209. > Let's "upgrade" this driver to support all the functions these pins can have. > > Then we add support to this driver for the AXP813 which is slighlty different > (basically a different offset in two registers and one less pin). > > I suggest patches 1 to 8 go through Linus's tree and 9 via Lee's. > > v5: > - add reference to pinctrl dt-bindings in driver's dt-binding, > - add statement that this driver employs per-pin muxing pattern, > - add a patch on top of the patch series to fix checkpatch warnings, > - add a few information to the Kconfig to make checkpatch happy, I have applied patches 1-8 to an immutable branch in the GPIO tree, then merged that into the GPIO "devel" branch as well as the pinctrl "devel" branch so we can develop the driver in the pinctrl tree henceforth. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 00/10] add pinmuxing support for pins in AXP209 and AXP813 PMICs
On Fri, Dec 1, 2017 at 2:44 PM, Quentin Schulz <quentin.sch...@free-electrons.com> wrote: > The AXP209 and AXP813 PMICs have several pins (respectively 3 and 2) that can > be used either as GPIOs or for other purposes (ADC or LDO here). > > We already have a GPIO driver for the GPIO use of those pins on the AXP209. > Let's "upgrade" this driver to support all the functions these pins can have. > > Then we add support to this driver for the AXP813 which is slighlty different > (basically a different offset in two registers and one less pin). > > I suggest patches 1 to 8 go through Linus's tree and 9 and 10 via Maxime or > Chen-Yu's tree. > > v4: Looks overall good. As soon as Maxime is happy with everything I will happily apply 1-8 to the pinctrl tree and then pull it to GPIO as well to avoid clashes. I think there were some minor comments but it seems almost finished. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 09/10] ARM: dtsi: axp81x: add GPIO DT node
On Fri, Dec 1, 2017 at 2:44 PM, Quentin Schulz <quentin.sch...@free-electrons.com> wrote: > This adds DT node for the GPIO/pinctrl part present in AXP813/AXP818. > > Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com> Acked-by: Linus Walleij <linus.wall...@linaro.org> Please apply this through ARM SoC. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 08/10] mfd: axp20x: add pinctrl cell for AXP813
On Fri, Dec 1, 2017 at 2:44 PM, Quentin Schulz <quentin.sch...@free-electrons.com> wrote: > As GPIO/pinctrl driver now supports AXP813, add a cell for it. > > Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com> > Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com> Acked-by: Linus Walleij <linus.wall...@linaro.org> It doesn't seem to have any dependencies so I guess Lee can simply apply this separately. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 03/10] dt-bindings: gpio: gpio-axp209: add pinctrl features
On Fri, Dec 1, 2017 at 2:44 PM, Quentin Schulz
<quentin.sch...@free-electrons.com> wrote:
> The X-Powers AXP209 has 3 GPIOs. GPIO0/1 can each act either as a GPIO,
> an ADC or a LDO regulator. GPIO2 can only act as a GPIO.
>
> This adds the pinctrl features to the driver so GPIO0/1 can be used as
> ADC or LDO regulator.
>
> Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com>
> Acked-by: Rob Herring <r...@kernel.org>
Please add a reference to the generic pinctrl bindings and state that you
use them and how.
pinctrl/pinctrl-bindings.txt
> +The GPIOs can be muxed to other functions and therefore, must be a subnode of
> +axp_gpio.
> +
> +Example:
> +
> +_gpio {
> + gpio0_adc: gpio0-adc {
> + pins = "GPIO0";
> + function = "adc";
> + };
> +};
So write explicitly that this driver employs the per-pin muxing pattern.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
On Fri, Nov 24, 2017 at 6:19 PM, Andre Przywara <andre.przyw...@arm.com> wrote: > Conceptually I consider the DT being > part of the firmware, As it is a subset of open firmware it is obviously firmware. > so one trust level above the kernel. We are several kernel developers who don't trust firmware one bit. Several disasters in ACPI has made me ever more convinced that firmware should be trusted less than kernel code. But this is all very academic. >> Also, device tree bindings are not documentation for how to write a >> driver. They are not a replacement for hardware documentation. Nobody >> should be expected to be able to write an OS driver solely based on a >> device tree binding. Device tree bindings are more of a configuration >> interface specification for OS drivers. > > Yes, but together with the hardware docs you should be able to write a > driver. And here you can't, because you are missing the strings. So a > BSD developer has to look at Linux code. This is a fair point. It appears in several drivers. BSD or even Windows (would they use DT) would have to sit in the back seat just like Linux has been doing for years when it comes to the hopeless Windowsisms in the x86 BIOSes. I suspect some Windows on ARM is already experiencing this, but in the ACPI world, where, incidentally, the servers were being deployed for Linux first and Windows had to follow their example. I bet they have been swearing a lot in Redmond about that. In general it's one of these areas where we can not be utopian about the hardware descriptions, just fail gracefully in different ways. I usually try to keep the IETF motto "rough consensus and running code" in mind. I don't know if it helps in this discussion though. >> So that's about 40% of the kernel image. Code really is no good without >> data to process. > > But how much of this is SoC specific configuration data? How much is it > in x86? Yes, historically we had and have a lot of configuration data in > ARM kernels. But that doesn't mean that we have to continue with this or > even increase the share. What people have been doing is trying to have better Kconfig setups and compile it out by doing kernel modules. It is a bit hopeless with pin controllers: almost all of them have to be built in. And if they come with a lot of data, yeah there you have a real good point. It would be sad if the ARMv7 multiboot or Aarch64 kernel just grows so that we can't use it but have to go back to shipping board-specific kernels with a huge bunch of stuff compiled out. I was hoping Moore's law would save us here :/ An option that has been discussed is better used of __initdata and similar tags, especially with built-in drivers. Sadly, this is hurt by another snag: the compiler or linker file or whatever it is, is preventing us from discarding any strings from the kernel. And pin controllers tend to stack up a lot of these. This is really sucky and something we should solve in general. I'm not smart enough to tackle any of these problems myself, just to see them and "Oh that's bad. Very bad." >> The majority of the improvements over the years have been achieved by >> moving drivers out of arch/arm and moving board files to DT. The goal >> was never to get rid of all data. > > Sure, not all data. But if we have the relatively easy opportunity to > avoid further addition of data, we should do it, I believe. > This significantly reduces the amount of kernel code we need to add to > support new SoCs. This is the core of your argument as I perceive it: get rid of data from the kernel, because it is growing wild. It is a valid cause. Just has to be weighed with other stuff, like maintainability, debuggability, maintainers viewpoint. ... Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
On Fri, Nov 24, 2017 at 6:19 PM, Andre Przywara <andre.przyw...@arm.com> wrote:
> On 24/11/17 13:31, Thierry Reding wrote:
>> Register values don't belong in a device tree.
>
> I don't think that's true in a general way. This "pinmux" is already an
> accepted property and used for exactly that purpose in other pinctrl
> drivers:
> $ git grep -l '[^,]pinmux = ' arch/arm{,64}/boot/dts
> Plus the fsl,pinmux-ids property, which seems to serve the same purpose.
There are several examples of register values (and register
numbers even!) being encoded in the kernel.
What we need to ask is whether that is good in the general case
or bad. I don't even think that has a clear answer, it's a grey area.
So we need to avoid "arguments from consistency" which reads
something like "you allowed this thing A so now you must allow
this thing B which is similar". It is not a helpful approach to the
problem.
Some drivers encode a bunch of data into the device tree,
pinctrl-single is the most extreme. This conflict between in-DT
and in-driver data storage has been there since pinctrl was created
and was the result of a compromise between OMAPs needs
and everyone else, especially Tegra.
The opinions on this - and it is really opinions, not facts - differ
between people and over time.
Resolving the conflicts is more about classical diplomacy than
science unfortunately. I used to think the christian trinity was
amusing and inconsistent, but nowadays I understand exactly how
the people who came up with the Nicean creed were reasoning.
What is paramount for me as subsystem maintainer is the fact
that this driver has an active maintainer. And maintainers
is what makes things manageable for me. It would be much easier
for you to have your way if you were submitting an entirely
new driver. Like this pinmux property, it was submitted by the
mediatek people because it fits their usecase/hardware especially
well.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/2] pinctrl: sunxi: Disable strict mode for H5 driver
On Sat, Nov 25, 2017 at 1:02 PM, Andre Przywara <andre.przyw...@arm.com> wrote: > All of the H5 boards in the kernel reference the MMC0 CD pin twice in > their DT, so strict mode will make the MMC driver fail to load. > To keep existing DTs working, disable strict mode in the H5 driver. > > Signed-off-by: Andre Przywara <andre.przyw...@arm.com> > Reported-by: Chris Obbard <obba...@gmail.com> Patch applied with Maxime's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: Fix A64 UART mux value
On Sat, Nov 25, 2017 at 1:12 PM, Andre Przywara <andre.przyw...@arm.com> wrote: > To use pin PF4 as the RX signal of UART0, we have to write 0b011 into > the respective pin controller register. > Fix the wrong value we had in our table so far. > > Signed-off-by: Andre Przywara <andre.przyw...@arm.com> Patch applied with Chen-Yu's ACK and fixes tag. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: Fix A80 interrupt pin bank
On Sat, Nov 25, 2017 at 1:19 PM, Andre Przywara <andre.przyw...@arm.com> wrote: > On the A80 the pins on port B can trigger interrupts, and those are > assigned to the second interrupt bank. > Having two pins assigned to the same interrupt bank/pin combination does > not look healthy (instead more like a copy bug from pins PA14-PA16), > so fix the interrupt bank for pins PB14-PB16, which is actually 1. > > I don't have any A80 board, so could not test this. > > Signed-off-by: Andre Przywara <andre.przyw...@arm.com> Patch applied with Chen-Yu's ACK and fixes tag. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH 0/3] pinctrl: sunxi: Add DT-based generic pinctrl driver
On Fri, Nov 24, 2017 at 1:05 PM, Andre Przywara <andre.przyw...@arm.com> wrote: > On 24/11/17 10:28, Linus Walleij wrote: >> The DT maintainers have been pretty clear on that they don't like >> using the the DT as a generic fit-all information dump. They >> prefer to look up hardware data from per-soc compatible strings. (...) > I am just a bit worried that with Allwinner recently playing the SKU > game we end up with tons of tables for only slightly different SoCs (see > the H3 and H5, for instance). And with single image kernels we pile up > quite some *data* in each kernel, which is of little interest for > everyone else. So what you are saying is that you want to use the DTS for data dumping and what I'm saying is that the DT maintainers do not like that stance. They will have to speak on the issue directly before we continue I think. I have been getting a *LOT* of pushback to putting large amounts of data and configuration in the DTS recently, so IIUC that is something they simply don't like, probably for good reasons. C.f: https://www.spinics.net/lists/dri-devel/msg150321.html > Also my understanding is that the actual Allwinner pin controller IP > (register map) is very much the same across all SoCs. Mostly the only > difference is the mapping between pins and mux functions, which we > express in the DT already anyway (in the subnodes). And this is really a > poster book example of what DT should be doing: express the specific > mappings of a particular implementation. I don't see why this would need > to be per-board only, if we can pull this up to the SoC level. It's not me you need to sell this point. You need to sell it to the DT maintainers. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 12/12] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs
On Wed, Oct 11, 2017 at 2:00 PM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > What about not enforcing any muxing state when we want to mux to the > "ldo" function? We just leave it to whatever value it is, that way we > keep it under the regulator framework's control, and we don't disrupt > anything when the pin is requested. In a way since setting the bits one way means "LDO on" and another setting means "LDO off" those bits should be handled by the regulator framework when used as a regulator, not pin control. So I would say yes. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 12/12] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs
On Wed, Oct 4, 2017 at 9:35 AM, Quentin Schulz <quentin.sch...@free-electrons.com> wrote: > Just to be a little more precise, > - 0: drive low > - 1: drive high > - 2: input with interrupt triggering > - 3: LDO on > - 4: LDO off > - 5~7: floating (or ADC) > > for AXP813, and > - 0: drive low > - 1: drive high > - 2: input with interrupt triggering > - 3: LDO on > - 4: ADC > - 5~7: floating Fair enough, it's mux modes that the pin supports, no big surprises. > So I think what you suggested Linus is not really relevant here as the > regulator framework will take care of disabling the regulator when > needed (for AXP813 via the ldo_off "muxing" selected by the regulator > framework). I think I see why I got confused. The point is that your mode for setting it to "LDO on" should have the pin control state connected to the relevant device. It should be connected to the regulator and nothing else, so if there is a fixed regulator or whatever in the device tree, it should have pinctrl-0 and pinctrl-names = ".."; here is is for some obscure reason connected to the GPIO controller (!) instead, and the actual consumer of this state is NOT the GPIO controller, but quite obviously the regulator, so put the pinctrl business in that regulator node instead. "default" mode is OK on a regulator, as that can be expected to make the pin precisely a regulator pin. Forget my ramblings about a "regulator" state. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 00/12] add pinmuxing support for pins in AXP209 and AXP813 PMICs
On Mon, Oct 2, 2017 at 2:08 PM, Quentin Schulz <quentin.sch...@free-electrons.com> wrote: > The AXP209 and AXP813 PMICs have several pins (respectively 3 and 2) that can > be used either as GPIOs or for other purposes (ADC or LDO here). > > We already have a GPIO driver for the GPIO use of those pins on the AXP209. > Let's "upgrade" this driver to support all the functions these pins can have. > > Then we add support to this driver for the AXP813 which is slighlty different > (basically a different offset in a register and one less pin). > > I suggest patches 1 to 6 go through Linus's tree and 7 to 12 via Maxime or > Chen-Yu's tree. > > This version of the patchset is based on Chen-Yu's patchset for AXP813/818 > regulators[1]. > > v3: This is starting to look really good, but I see there are still comments. Keep the series going, we merge once Maxime and Chen-Yu are happy. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 12/12] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs
On Mon, Oct 2, 2017 at 2:08 PM, Quentin Schulz
<quentin.sch...@free-electrons.com> wrote:
> On AXP813/818, GPIO0 and GPIO1 can be used as LDO as (respectively)
> ldo_io0 and ldo_io1.
(...)
> + gpio0_ldo: gpio0_ldo {
> + pins = "GPIO0";
> + function = "ldo";
> + };
(...)
> + pinctrl-names = "default";
> + pinctrl-0 = <_ldo>;
> /* Disable by default to avoid conflicts with GPIO */
> status = "disabled";
So this is still by default disabled, but you make the default
mode something called "ldo".
And I think that is to be understood as a low-dropout regulator?
So is the idea that this should be represented as a regulator
in the end?
Then I think the state name should not be "default" rather
something like "regulator" and "default" should be the GPIO
mode, as I guess something like that exists.
Activating a regulator using pin control "default" mode is
not very pretty. It would probably be unintuitive and end
up wasting power because people will get confused about
what is going on.
Instead, call this state "regulator" and when using, in Linux
create a regulator device that set the pin into "regulator" state to
start using it as a LDO, and "default" to deactivate it as
LDO, if that is how the usage is intended.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] Revert "pinctrl: sunxi: Don't enforce bias disable (for now)"
On Sun, Aug 27, 2017 at 2:55 PM, Priit Laes <pl...@plaes.org> wrote: > This reverts commit 2154d94b40ea2a5de05245521371d0461bb0d669. > > The original patch was intented to avoid some issues with the sunxi > gpio rework and was supposed to be reverted after all the required > DT bits had been merged around v4.10. > > Signed-off-by: Priit Laes <pl...@plaes.org> Patch applied with Maxime's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/2] pinctrl: sunxi: fix wrong irq_banks number for H5 pinctrl
On Fri, Aug 11, 2017 at 4:27 PM, Icenowy Zheng <icen...@aosc.io> wrote:
> The pin controller of Allwinner H5 has three IRQ banks, however in old
> versions of drivers and device trees, only two are set, which makes
> PG bank IRQ not available.
>
> If it's directly set to 3, the old device trees will fail to boot.
>
> Add a workaround (and a warning) for older device trees, and allow new
> device trees to use correct 3 IRQ banks.
>
> Fixes: 838adb576d4a ("drivers: pinctrl: add driver for Allwinner H5 SoC")
> Signed-off-by: Icenowy Zheng <icen...@aosc.io>
Patch applied with Chen-Yu's ACK.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: fix V3s pinctrl driver IRQ bank base
On Tue, Aug 1, 2017 at 4:54 PM, Icenowy Zheng <icen...@aosc.io> wrote:
> The V3s pin controller doesn't have the bank 0 (starts at address
> 0x200), which is like A33. However, this is not workarounded when
> developing the driver, which makes IRQ not working.
>
> Fix the IRQ bank base.
>
> Fixes: 56d9e4a76039 ("pinctrl: sunxi: add driver for V3s SoC")
> Cc: sta...@vger.kernel.org
This patch only applies on the devel branch so I don't see why it is tagged
for stable.
> Signed-off-by: Icenowy Zheng <icen...@aosc.io>
Patch applied.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: rename R_PIO i2c pin function name
On Sun, Jul 30, 2017 at 7:36 AM, Icenowy Zheng <icen...@aosc.io> wrote: > The I2C pin functions in R_PIO used to be named "s_twi". > > As we usually use the name "i2c" instead of "twi" in the mainline > kernel, change these names to "s_i2c" for consistency. > > The "s_twi" functions are not yet referenced by any device trees in > mainline kernel so I think it's safe to change the name. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> Patch applied with Chen-Yu's review tag. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 2/2] pinctrl: sunxi: add support of R40 to A10 pinctrl driver
2017-07-22 4:50 GMT+02:00 Icenowy Zheng <icen...@aosc.io>: > R40 is said to be an upgrade of A20, and its pin configuration is also > similar to A20 (and thus similar to A10). > > Add support for R40 to the A10 pinctrl driver. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > Reviewed-by: Chen-Yu Tsai <w...@csie.org> > --- > Changes in v3: Patch applied for next. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 1/2] pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver
On Sat, Jul 22, 2017 at 4:50 AM, Icenowy Zheng <icen...@aosc.io> wrote:
> The PH16 pin has a function with mux id 0x5, which is the DET pin of the
> "sim" (smart card reader) IP block.
>
> This function is missing in old versions of A10/A20 SoCs' datasheets and
> user manuals, so it's also missing in the old drivers. The newest A10
> Datasheet V1.70 and A20 Datasheet V1.41 contain this pin function, and
> it's discovered during implementing R40 pinctrl driver.
>
> Add it to the driver. As we now merged A20 pinctrl driver to the A10
> one, we need to only fix the A10 driver now.
>
> Fixes: f2821b1ca3a2 ("pinctrl: sunxi: Move Allwinner A10 pinctrl
> driver to a driver of its own")
>
> Signed-off-by: Icenowy Zheng <icen...@aosc.io>
> Reviewed-by: Chen-Yu Tsai <w...@csie.org>
> ---
> Changes in v3:
Patch applied for fixes.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 0/2] Last step to working Allwinner R40 pinctrl
On Sun, Jul 30, 2017 at 7:26 AM, <icen...@aosc.io> wrote: > 在 2017-07-22 10:50，Icenowy Zheng 写道： >> >> This patchset contains only two patches. >> >> The first one is a minor fix for the A10 pinctrl driver, add a function >> of a pin, which used to be missing in A10/A20 pinctrl driver. Thanks for >> Chen-Yu for discovering it when reviewing my R40 pinctrl patchset. >> >> The second one is the real R40 pinctrl part, with fixes suggested by >> Chen-Yu and Maxime. >> >> Icenowy Zheng (2): >> pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver >> pinctrl: sunxi: add support of R40 to A10 pinctrl driver > > > Ping... > > Can anyone process this patchset? Sorry, I was on vacation. Looking at the backlog now. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 3/3] ARM: sun8i: a83t: Add device node for R_PIO
On Sat, Jun 3, 2017 at 4:44 PM, Chen-Yu Tsai <w...@csie.org> wrote: > The A83T has 1 pingroup with 13 pins belonging to the R_PIO > or special pin controller. > > Signed-off-by: Chen-Yu Tsai <w...@csie.org> Acked-by: Linus Walleij <linus.wall...@linaro.org> Pls funnel this through the ARM SoC tree. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/3] pinctrl: sunxi: Add support for A83T R_PIO
On Sat, Jun 3, 2017 at 4:44 PM, Chen-Yu Tsai <w...@csie.org> wrote: > The R_PIO on the A83T is almost the same as the one found on the A64, > except that the CIR_RX function was moved from pin PL11 to pin PL12. > > Add a driver for it. > > Signed-off-by: Chen-Yu Tsai <w...@csie.org> Patch applied. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/3] dt-bindings: pinctrl: sunxi: Add compatible string for A83T R_PIO
On Sat, Jun 3, 2017 at 4:44 PM, Chen-Yu Tsai <w...@csie.org> wrote: > The R_PIO on the A83T is almost the same as the one found on the A64, > except that the CIR_RX function was moved from pin PL11 to pin PL12. > > Add a compatible string for it. > > Signed-off-by: Chen-Yu Tsai <w...@csie.org> Patch applied with Rob's ACK. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 3/6] pinctrl: sunxi: Fix SPDIF function name for A83T
On Mon, May 22, 2017 at 8:25 AM, Chen-Yu Tsai <w...@csie.org> wrote:
> We use well known standard names for functions that have name, such as
> I2C, SPI, SPDIF, etc..
>
> Fix the function name of SPDIF, which was named OWA (One Wire Audio)
> based on Allwinner datasheets.
>
> Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller
> support")
> Signed-off-by: Chen-Yu Tsai <w...@csie.org>
Patch applied for fixes with Maxime's ACK.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: use non-devm kmalloc versions for free functions
On Fri, May 12, 2017 at 7:14 PM, Tony Lindgren <t...@atomide.com> wrote:
> From tony Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <t...@atomide.com>
> Date: Fri, 12 May 2017 08:47:57 -0700
> Subject: [PATCH] pinctrl: core: Fix warning by removing bogus code
>
> Andre Przywara <andre.przyw...@arm.com> noticed that we can get the
> following warning with -EPROBE_DEFER:
>
> "WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349
> driver_probe_device+0x2ac/0x2e8"
>
> Let's fix the issue by removing the indices as suggested by
> Tejun Heo <t...@kernel.org>. All we have to do here is kill the radix
> tree.
>
> I probably ended up with the indices after grepping for removal
> of all entries using radix_tree_for_each_slot() and the first
> match found was gmap_radix_tree_free(). Anyways, no need for
> indices here, and we can just do remove all the entries using
> radix_tree_for_each_slot() along how the item_kill_tree() test
> case does.
>
> Fixes: c7059c5ac70a ("pinctrl: core: Add generic pinctrl functions
> for managing groups")
> Fixes: a76edc89b100 ("pinctrl: core: Add generic pinctrl functions
> for managing groups")
> Reported-by: Andre Przywara <andre.przyw...@arm.com>
> Signed-off-by: Tony Lindgren <t...@atomide.com>
Thanks! This nice inline patch applied for fixes with André's tags.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 00/10] Initial Allwinner R40 support
On Thu, May 4, 2017 at 3:49 PM, Icenowy Zheng <icen...@aosc.io> wrote: > This is the first non-RFC version of this patchset, which added basical > support including I2C, UART and MMC to the mainline Linux. > > The pinctrl driver of A20 is also merged into the one of A10 before > R40 support is added into the A10 driver. I'd be happy to merge the pinctrl parts as soon as you fixed the things pointed out during review. Include Rob's ACKs on the DT binding patches please. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: use non-devm kmalloc versions for free functions
On Thu, May 11, 2017 at 4:20 PM, Andre Przywara <andre.przyw...@arm.com> wrote: >> On Thu, May 4, 2017 at 1:57 AM, Andre Przywara <andre.przyw...@arm.com> >> wrote: >> >>> When a pinctrl driver gets interrupted during its probe process >>> (returning -EPROBE_DEFER), the devres system cleans up all allocated >>> resources. During this process it calls pinmux_generic_free_functions() >>> and pinctrl_generic_free_groups(), which in turn use managed kmalloc >>> calls for temporarily allocating some memory. Now those calls seem to >>> get added to the devres list, but are apparently not covered by the >>> cleanup process, because this is actually just running and iterating the >>> existing list. This leads to those mallocs being left with the device, >>> which the devres manager complains about when the driver eventually gets >>> probed again: >>> [0.825239] [ cut here ] >>> [0.825256] WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349 >>> driver_probe_device+0x2ac/0x2e8 >>> [0.825258] Modules linked in: >>> [0.825262] >>> [0.825270] CPU: 1 PID: 89 Comm: kworker/1:1 Not tainted 4.11.0 #307 >>> [0.825272] Hardware name: Pine64+ (DT) >>> [0.825283] Workqueue: events deferred_probe_work_func >>> [0.825288] task: 80007c19c100 task.stack: 80007c16c000 >>> [0.825292] PC is at driver_probe_device+0x2ac/0x2e8 >>> [0.825296] LR is at driver_probe_device+0x108/0x2e8 >>> [0.825300] pc : [] lr : [] pstate: >>> 2045 >>> >>> This warning is triggered because the devres list is not empty. In this >>> case the allocations were using 0 bytes, so no real leaks, but still this >>> ugly warning. >>> Looking more closely at these *cleanup* functions, devm_kzalloc() is >>> actually >>> not needed, because the memory is just allocated temporarily and can be >>> freed just before returning from this function. >>> So fix this issue by using the bog standard kcalloc() call instead of >>> devm_kzalloc() and kfree()ing the memory at the end. >>> >>> This fixes above warnings on boot, which can be observed on *some* builds >>> for the Pine64, where the pinctrl driver gets loaded early, but it missing >>> resources, so gets deferred and is loaded again (successfully) later. >>> kernelci caught this as well [1]. >>> >>> Signed-off-by: Andre Przywara <andre.przyw...@arm.com> >>> >>> [1] >>> https://storage.kernelci.org/net-next/master/v4.11-rc8-2122-gc08bac03d289/arm64/defconfig/lab-baylibre-seattle/boot-sun50i-a64-pine64-plus.html >>> --- >>> Hi, >>> >>> not sure this is the right fix, I am open to suggestions. >> >> I have queued this as a tentative v4.12-rc1 fix, but a bit undertain. >> >> Tejun, do I read your comments on the patch as an ACK? > > Tejun and I were wondering why we need this "create an array with the > indices" in the first place. If we can just call radix_tree_delete() > directly from the radix_tree_for_each_slot() loop, we can have a much > better fix (omitting the memory allocation at all) OK I pulled the patch out again for now. > Linus, can you shed some light if this array creation serves some purpose? Tony [author of this function] can you look at this? The code in pinctrl_generic_free_groups() does look a bit weird, allocating these indices just to remove the radix tree. Do you think we can clean it up? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 04/10] pinctrl: sunxi: switch A20's pinctrl driver to use the A10 version
On Thu, May 4, 2017 at 3:50 PM, Icenowy Zheng <icen...@aosc.io> wrote: > As we added A20 support to A10 pinctrl driver, now we can delete the > dedicated A20 pinctrl driver, and enable A10 driver for A20. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> Looks all right to me but I'm waiting for Maxime's review on these patches. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: use non-devm kmalloc versions for free functions
On Thu, May 4, 2017 at 1:57 AM, Andre Przywara <andre.przyw...@arm.com> wrote: > When a pinctrl driver gets interrupted during its probe process > (returning -EPROBE_DEFER), the devres system cleans up all allocated > resources. During this process it calls pinmux_generic_free_functions() > and pinctrl_generic_free_groups(), which in turn use managed kmalloc > calls for temporarily allocating some memory. Now those calls seem to > get added to the devres list, but are apparently not covered by the > cleanup process, because this is actually just running and iterating the > existing list. This leads to those mallocs being left with the device, > which the devres manager complains about when the driver eventually gets > probed again: > [0.825239] [ cut here ] > [0.825256] WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349 > driver_probe_device+0x2ac/0x2e8 > [0.825258] Modules linked in: > [0.825262] > [0.825270] CPU: 1 PID: 89 Comm: kworker/1:1 Not tainted 4.11.0 #307 > [0.825272] Hardware name: Pine64+ (DT) > [0.825283] Workqueue: events deferred_probe_work_func > [0.825288] task: 80007c19c100 task.stack: 80007c16c000 > [0.825292] PC is at driver_probe_device+0x2ac/0x2e8 > [0.825296] LR is at driver_probe_device+0x108/0x2e8 > [0.825300] pc : [] lr : [] pstate: > 2045 > > This warning is triggered because the devres list is not empty. In this > case the allocations were using 0 bytes, so no real leaks, but still this > ugly warning. > Looking more closely at these *cleanup* functions, devm_kzalloc() is actually > not needed, because the memory is just allocated temporarily and can be > freed just before returning from this function. > So fix this issue by using the bog standard kcalloc() call instead of > devm_kzalloc() and kfree()ing the memory at the end. > > This fixes above warnings on boot, which can be observed on *some* builds > for the Pine64, where the pinctrl driver gets loaded early, but it missing > resources, so gets deferred and is loaded again (successfully) later. > kernelci caught this as well [1]. > > Signed-off-by: Andre Przywara <andre.przyw...@arm.com> > > [1] > https://storage.kernelci.org/net-next/master/v4.11-rc8-2122-gc08bac03d289/arm64/defconfig/lab-baylibre-seattle/boot-sun50i-a64-pine64-plus.html > --- > Hi, > > not sure this is the right fix, I am open to suggestions. I have queued this as a tentative v4.12-rc1 fix, but a bit undertain. Tejun, do I read your comments on the patch as an ACK? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 10/10] ARM: dts: sun8i: Add board dts file for Banana Pi M2 Ultra
On Thu, May 4, 2017 at 3:50 PM, Icenowy Zheng <icen...@aosc.io> wrote:
> From: Chen-Yu Tsai <w...@csie.org>
>
> The Banana Pi M2 Ultra is an SBC based on the Allwinner R40 SoC. The
> form factor and position of various connectors, leds and buttons is
> similar to the Banana Pi M1+, Banana Pi M3, and is exactly the same
> as the latest Banana Pi M64.
>
> It features:
>
> - X-Powers AXP221s PMIC connected to i2c0
> - 2 GB DDR3 DRAM
> - 8 GB eMMC
> - micro SD card slot
> - DC power jack
> - HDMI output
> - MIPI DSI connector
> - 2x USB 2.0 hosts
> - 1x USB 2.0 OTG
> - gigabit ethernet with Realtek RTL8211E transceiver
> - WiFi/Bluetooth with AP6212 chip, with external antenna connector
> - SATA and power connectors for native SATA support
> - camera sensor connector
> - consumer IR receiver
> - audio out headphone jack
> - onboard microphone
> - red, green, and blue LEDs
> - debug UART pins
> - Li-Po battery connector
> - Raspberry Pi B+ compatible GPIO header
> - power, reset, and boot control buttons
>
> This patch adds a dts file that enables debug UART and MMC support.
>
> Signed-off-by: Chen-Yu Tsai <w...@csie.org>
> Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
Eric put a lot of time and effort into naming the GPIO lines on the
other Pi board.
So please follow the good example and name the GPIO lines on this board
like in the other rpi boards, should be something like:
{
gpio-line-names = "...", "...";
};
This is very helpful for users.
Yours,
Linus Walleij
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] pinctrl: sunxi: select GPIOLIB
On Tue, Feb 28, 2017 at 8:08 PM, Icenowy Zheng <icen...@aosc.xyz> wrote: > Allwinner pin controllers are also GPIO controllers. > > Currently, if GPIOLIB is forgot to be chosen, the build of > pinctrl-sunxi.c will fail for lacking a lot of gpiochip_* functions. > > Select GPIOLIB to ensure this driver can be built. > > Signed-off-by: Icenowy Zheng <icen...@aosc.xyz> > --- > This bug is found when I try to add sunxi drivers on an ARM64 > allnoconfig, in order to prove that sunxi-ng ccu driver depends on > reset_controller framework. > > I proved the latter dependency, but how to satisfy it still needs > some discussion. Patch applied. This is the right thing to do. We used to have a restriction such that a pin control driver could not simply select GPIOLIB, because the selection had to be done from the platform instead. But we have fixed that! We can now select GPIOLIB directly from any driver that needs it. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH 0/9] Add support for Allwinner R40 SoC
On Fri, Feb 17, 2017 at 6:37 PM, Icenowy Zheng <icen...@aosc.xyz> wrote: > This patchset is an experiment to add R40 support to mainline Linux. > > As we have still no user manual for R40, the patchset is developed > by reading the BSP source code and device tree, educated guess and > try and error. Out of curiosity: does the board support use the mainline drivers as starting point? I.e. does it build on top of the community work done by Maxime & others? Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 3/8] pinctrl: sunxi: Add A64 R_PIO controller support
On Wed, Feb 8, 2017 at 11:00 AM, Icenowy Zheng <icen...@aosc.xyz> wrote: > The A64 has a R_PIO pin controller, similar to the one found on the H3 SoC. > Add support for the pins controlled by the R_PIO controller. > > Signed-off-by: Icenowy Zheng <icen...@aosc.xyz> I'd be happy to merge patches 1,2 & 3 to the pinctrl tree but I need a maintainer ACK on these three patches first. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 01/10] drivers: pinctrl: add driver for Allwinner H5 SoC
On Sun, Jan 29, 2017 at 3:33 AM, Icenowy Zheng <icen...@aosc.xyz> wrote: > Based on the Allwinner H5 datasheet and the pinctrl driver of the > backward-compatible H3 this introduces the pin multiplex assignments for > the H5 SoC. > > H5 introduced some more pin functions (e.g. three more groups of TS > pins, and one more groups of SIM pins) than H3. > > Signed-off-by: Icenowy Zheng <icen...@aosc.xyz> > Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com> > --- > Changes in v3: > - Add Maxime's ACK. > Changes in v2: > - Fixed interrupt banks. (There's one more GPIO banks (PF) that can do > interrupt handling on H5) I already applied V2 with Maximes' ACK and all. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
