[linux-sunxi] Re: [PATCH] arm64: dts: allwinner: a64: Fix USB OTG regulator
On Wed, Jan 09, 2019 at 07:16:04PM +0100, Jernej Skrabec wrote:
> Currently, AXP803 driver assumes that reg_drivevbus is input which is
> wrong. Unfortunate consequence of that is that none of the USB ports
> work on the board, even USB HOST port, because USB PHY driver probing
> fails due to missing regulator.
>
> Fix that by adding "x-powers,drive-vbus-en" property to AXP803 node.
>
> Fixes: 14ff5d8f9151 ("arm64: dts: allwinner: a64: Orange Pi Win: Enable USB
> OTG socket")
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jernej Skrabec
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
[linux-sunxi] Re: [PATCH v5 02/26] reset: Add Allwinner RESET driver
On 31/12/2018 16:59, Jagan Teki wrote:
> Add common reset driver for all Allwinner SoC's.
>
> Since CLK and RESET share common DT compatible, it is CLK driver
> job is to bind the reset driver. So add CLK bind call on respective
> SoC driver by passing ccu map descriptor so-that reset deassert,
> deassert operations held based on ccu reset table defined from
> CLK driver.
>
> Select DM_RESET via CLK_SUNXI, this make hidden section of RESET
> since CLK and RESET share common DT compatible and code.
>
> Signed-off-by: Jagan Teki
> Acked-by: Maxime Ripard
> ---
> arch/arm/include/asm/arch-sunxi/ccu.h | 29 ++
> drivers/clk/sunxi/Kconfig | 1 +
> drivers/clk/sunxi/clk_a64.c | 20 +
> drivers/reset/Kconfig | 8 ++
> drivers/reset/Makefile| 1 +
> drivers/reset/reset-sunxi.c | 125 ++
> 6 files changed, 184 insertions(+)
> create mode 100644 drivers/reset/reset-sunxi.c
>
> diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h
> b/arch/arm/include/asm/arch-sunxi/ccu.h
> index db69c8f0d5..3fdc26978d 100644
> --- a/arch/arm/include/asm/arch-sunxi/ccu.h
> +++ b/arch/arm/include/asm/arch-sunxi/ccu.h
> @@ -34,13 +34,33 @@ struct ccu_clk_gate {
> .flags = CCU_CLK_F_INIT_DONE, \
> }
>
> +/**
> + * struct ccu_reset - ccu reset
> + * @off: reset offset
> + * @bit: reset bit
> + * @flags: reset flags
> + */
> +struct ccu_reset {
> + u16 off;
> + u32 bit;
> + enum ccu_clk_flags flags;
> +};
> +
> +#define RESET(_off, _bit) { \
> + .off = _off,\
> + .bit = _bit,\
> + .flags = CCU_CLK_F_INIT_DONE, \
> +}
> +
> /**
> * struct ccu_desc - clock control unit descriptor
> *
> * @gates: clock gates
> + * @resets: reset unit
> */
> struct ccu_desc {
> const struct ccu_clk_gate *gates;
> + const struct ccu_reset *resets;
> };
>
> /**
> @@ -62,4 +82,13 @@ int sunxi_clk_probe(struct udevice *dev);
>
> extern struct clk_ops sunxi_clk_ops;
>
> +/**
> + * sunxi_reset_bind() - reset binding
> + *
> + * @dev: reset device
> + * @count: reset count
> + * @return 0 success, or error value
> + */
> +int sunxi_reset_bind(struct udevice *dev, ulong count);
> +
> #endif /* _ASM_ARCH_CCU_H */
> diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
> index bf5ecb3801..041d711e58 100644
> --- a/drivers/clk/sunxi/Kconfig
> +++ b/drivers/clk/sunxi/Kconfig
> @@ -1,6 +1,7 @@
> config CLK_SUNXI
> bool "Clock support for Allwinner SoCs"
> depends on CLK && ARCH_SUNXI
> + select DM_RESET
> default y
> help
> This enables support for common clock driver API on Allwinner
> diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
> index 803a2f711d..28bda1f497 100644
> --- a/drivers/clk/sunxi/clk_a64.c
> +++ b/drivers/clk/sunxi/clk_a64.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> static const struct ccu_clk_gate a64_gates[] = {
> [CLK_BUS_OTG] = GATE(0x060, BIT(23)),
> @@ -26,10 +27,28 @@ static const struct ccu_clk_gate a64_gates[] = {
> [CLK_USB_OHCI1] = GATE(0x0cc, BIT(17)),
> };
>
> +static const struct ccu_reset a64_resets[] = {
> + [RST_USB_PHY0] = RESET(0x0cc, BIT(0)),
> + [RST_USB_PHY1] = RESET(0x0cc, BIT(1)),
> + [RST_USB_HSIC] = RESET(0x0cc, BIT(2)),
> +
> + [RST_BUS_OTG] = RESET(0x2c0, BIT(23)),
> + [RST_BUS_EHCI0] = RESET(0x2c0, BIT(24)),
> + [RST_BUS_EHCI1] = RESET(0x2c0, BIT(25)),
> + [RST_BUS_OHCI0] = RESET(0x2c0, BIT(28)),
> + [RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
> +};
> +
> static const struct ccu_desc a64_ccu_desc = {
> .gates = a64_gates,
> + .resets = a64_resets,
> };
>
> +static int a64_clk_bind(struct udevice *dev)
> +{
> + return sunxi_reset_bind(dev, 50);
The second parameter is count, so it should be 51. But this is wrong
either way, so just use ARRAY_SIZE(a64_reset), as this is what you are
after with the check later on.
Same for the other SoCs, of course.
> +}
> +
> static const struct udevice_id a64_ccu_ids[] = {
> { .compatible = "allwinner,sun50i-a64-ccu",
> .data = (ulong)_ccu_desc },
> @@ -43,4 +62,5 @@ U_BOOT_DRIVER(clk_sun50i_a64) = {
> .priv_auto_alloc_size = sizeof(struct ccu_priv),
> .ops= _clk_ops,
> .probe = sunxi_clk_probe,
> + .bind = a64_clk_bind,
> };
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 9c5208b7da..b6b40b6ce9 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -106,4 +106,12 @@ config RESET_SOCFPGA
> help
> Support for reset controller on SoCFPGA platform.
>
> +config RESET_SUNXI
> + bool "RESET support for Allwinner SoCs"
> + depends
[linux-sunxi] Re: [PATCH v5 15/26] clk: sunxi: Add ccu clock tree support
On 08/01/2019 19:12, Jagan Teki wrote: > On Tue, Jan 8, 2019 at 5:09 PM Andre Przywara wrote: >> >> On Tue, 8 Jan 2019 16:27:14 +0530 >> Jagan Teki wrote: >> >> Hi, >> >>> On Mon, Jan 7, 2019 at 6:35 AM André Przywara >>> wrote: On 31/12/2018 16:59, Jagan Teki wrote: > Clock control unit comprises of parent clocks, gates, > multiplexers, dividers, multipliers, pre/post dividers and flags > etc. > > So, the U-Boot implementation of ccu has divided into gates and > tree. gates are generic clock configuration of enable/disable bit > management which can be handle via ccu_clock_gate. So if I understand this correctly, you implement the gate functionality separately from the complex clock code, even if they are the same clock from the DT point of view? So if one wants to enable the MMC0 clock, which is a mux/divider clock, one needs to specify an extra entry in the gate array to describe the enable bit in this special clock register? Sounds a bit surprising, but is probably a neat trick to keep things simple. There should be a comment in the code to this regard then. >>> >>> Exactly. Idea is to keep the macro's as simple as possible. >>> >>> Adding gates clocks separately make easy and reasonable way to >>> enable/disable clock operations. We even operate with single macro >>> with all clock attributes along with gate(either another member or >>> common structure like Linux does), but that seems not simple as per as >>> my experince since there are many IP's like USB's just need >>> enable/disable. >>> > Tree clocks are parent clock type, fixed clocks, mp, nk, nkm, > nkmp, pre/post div, flags etc. which were managed via > ccu_clock_tree. For a start, can we use more descriptive names than those very specific MP/NK names? DIV_MUX and PLL sound more descriptive to me. I understand that Linux uses those terms, but it would be great if uninitiated people have a chance to understand this as well. > This patch add support for MP, NK, MISC, FIXED clock types as > part of ccu clock tree with get_rate functionality this > eventually used by uart driver. and rest of the infrastructure > will try to add while CLK is being used on respective peripherals. > > Note that few of the tree type clock would require to enable > gates on their specific clock, in that case we need to add the > gate details via ccu_clock_gate, example: MP with gate so the > gate offset, bit value should add as part of ccu_clock_gate. > > Signed-off-by: Jagan Teki > --- > arch/arm/include/asm/arch-sunxi/ccu.h | 192 > +- drivers/clk/sunxi/clk_a64.c > | 40 ++ drivers/clk/sunxi/clk_sunxi.c | 182 > 3 files changed, 413 insertions(+), 1 > deletion(-) > > diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h > b/arch/arm/include/asm/arch-sunxi/ccu.h index > 3fdc26978d..61b8c36b3b 100644 --- > a/arch/arm/include/asm/arch-sunxi/ccu.h +++ > b/arch/arm/include/asm/arch-sunxi/ccu.h @@ -7,15 +7,204 @@ > #ifndef _ASM_ARCH_CCU_H > #define _ASM_ARCH_CCU_H > > +#define OSC_32K_ULL 32000ULL 32768 And why ULL? The whole Allwinner clock system works with 32-bit values, so just U would be totally sufficient. This avoid blowing this up to 64 bit unnecessarily, which sounds painful for those poor ARMv7 parts. > +#define OSC_24M_ULL 2400ULL > + > +/** > + * enum ccu_clk_type - ccu clock types > + * > + * @CCU_CLK_TYPE_MISC: misc clock type What is MISC, exactly? Seems like an artefact clock to me, some placeholder you need because gate clocks are handled separately in the gates struct. Should this be called something with SIMPLE instead, or GATE? >>> >>> Unlike MP type in MMC, UART doesn't need any clock attributes like >>> dividers, mux, etc, just have attached parent. I don't think UART >>> clock is simple one It has parent, that indeed have another parents >>> and so...on, ie reason I named as MISC. >> >> Not really, as far as I can see the UART clock is a just a gate clock as >> many others, with one parent (APB2). >> The fact that APB2 in turn can have multiple parents doesn't affect the >> UART clock itself, as you model this via the clock tree. >> >> In fact we could have similar clocks in the tree structure for the >> other gate clocks (USB, for instance), it's just that the UART is the >> only user so far which actually queries the clock rate. >> >> So MISC is way too generic, I would still prefer CCU_CLK_TYPE_GATE. > > TYPE_GATE is more sense. fine for me. > >> > + * @CCU_CLK_TYPE_FIXED: fixed clock type > + * @CCU_CLK_TYPE_MP: mp clock type > + * @CCU_CLK_TYPE_NK: nk clock
Re: [linux-sunxi] u-boot: MMC broken on Linksprite A10/A20 boards in 2018.11
Hi Jagan, After applying your patch on v2019.1-rc3 and defining CONFIG_DM_MMC, u-boot finally initialize MMC and boots kernel without any problems on A10-OLinuXino-Lime. :) Thank you for your fix. Marek Kraus Dňa streda, 9. januára 2019 12:28:37 UTC+1 Jagan Teki napísal(-a): > > On Wed, Jan 9, 2019 at 1:08 AM Priit Laes > > wrote: > > > > On Tue, Jan 08, 2019 at 11:54:32PM +0530, Jagan Teki wrote: > > > On Thu, Jan 3, 2019 at 9:33 PM Zoltan HERPAI > wrote: > > > > > > > > Hi Jagan, Adam, > > > > > > > > On Thu, 3 Jan 2019, Jagan Teki wrote: > > > > > > > > > On Thu, Jan 3, 2019 at 6:57 PM Zoltan HERPAI > wrote: > > > > >> > > > > >> Hi all, > > > > >> > > > > >> The DTS resync between 2018.09 and 2018.11 seems to have broken > the MMC > > > > >> support for the Linksprite pcDuino (A10) and pcDuino v3 (A20) > boards. > > > > >> The resync happened in b9d59d0 [1] and 3c92cca [2], after which > u-boot > > > > >> doesn't recognize the MMC controller and freezes the board > (exactly the > > > > >> same happens on the v3 board). > > > > >> > > > > >> CUT HERE > > > > >> U-Boot SPL 2018.11 (Dec 31 2018 - 14:36:52 +) > > > > >> DRAM: 1024 MiB > > > > >> CPU: 100800Hz, AXI/AHB/APB: 3/2/2 > > > > >> Trying to boot from MMC1 > > > > >> > > > > >> > > > > >> U-Boot 2018.11 (Dec 31 2018 - 14:36:52 +) Allwinner > Technology > > > > >> > > > > >> CPU: Allwinner A10 (SUN4I) > > > > >> Model: LinkSprite pcDuino > > > > >> I2C: ready > > > > >> DRAM: 1 GiB > > > > >> MMC: > > > > >> CUT HERE > > > > >> > > > > >> Reverting these commits solve the problem and the boards boot > correctly. > > > > >> Initially I thought this might be due to removing the > > > > >> mmc0_cd_pin_reference_design (syncing that from the kernel into > u-boot), > > > > >> which was discussed here [3] and was considered as a move that > might > > > > >> break MMC on some boards, but re-adding that reference pin only > in the > > > > >> pcduino DTSes did not resolve the freeze. > > > > >> > > > > >> Questions: > > > > >> - A similar board - where the reference pin is used for CD - is > the > > > > >> Cubieboard 2. Can someone test 2018.11 on it to see if it freezes > as > > > > >> well? Out of A20, I have a Bananapro, but that's using a > non-reference > > > > >> pin for CD, and boots fine. > > > > > > > > > > A10, enable DM_MMC so it can effect DT. or enable > CONFIG_MMC0_CD_PIN="PH1" > > > > > > > > > > Added Adam, (who actually tested DM_MMC on A10) > > > > > > > > I tested with "either" and "both", neither worked - see below. Along > with > > > > CONFIG_DM_MMC, I've also enabled CONFIG_DM_DEBUG to see what's > happening - > > > > here is the output: > > > > > > > > [...] > > > > MMC: uclass_find_device_by_seq: 0 0 > > > > - -1 -1 'mmc@1c0f000' > > > > - not found > > > > uclass_find_device_by_seq: 1 0 > > > > - -1 -1 'mmc@1c0f000' > > > > - not found > > > > uclass_find_device_by_seq: 0 -1 > > > > uclass_find_device_by_seq: 0 0 > > > > - -1 -1 'mmc@1c0f000' > > > > - not found > > > > Entering sunxi_mmc_probe > > > > ofnode_read_u32: bus-width: 0x4 (4) > > > > sunxi_mmc: priv->reg: 1c0f000 > > > > sunxi_mmc: priv->mclkreg: 1c2 > > > > > > I'm looking for gate and clk register values, print at the end of > probe > > > 1c2 + 0x60 > > > 1c2 + 0x88 > > > > With current master: > > sunxi_mmc_probe: gate_reg: 0x4141 > > sunxi_mmc_probe: clk_reg: 0x0 > > Please check this gist [1] > > [1] https://gist.github.com/openedev/e76ef26f75f133883f295225efb5b4bd > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH] arm64: dts: allwinner: a64: Fix USB OTG regulator
Currently, AXP803 driver assumes that reg_drivevbus is input which is
wrong. Unfortunate consequence of that is that none of the USB ports
work on the board, even USB HOST port, because USB PHY driver probing
fails due to missing regulator.
Fix that by adding "x-powers,drive-vbus-en" property to AXP803 node.
Fixes: 14ff5d8f9151 ("arm64: dts: allwinner: a64: Orange Pi Win: Enable USB OTG
socket")
Cc: sta...@vger.kernel.org
Signed-off-by: Jernej Skrabec
---
arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
index b0c64f75792c..8974b5a1d3b1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
@@ -188,6 +188,7 @@
reg = <0x3a3>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ x-powers,drive-vbus-en; /* set N_VBUSEN as output pin */
};
};
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/2] media: cedrus: Allow using the current dst buffer as reference
On 01/09/19 15:42, Paul Kocialkowski wrote:
> Hi,
>
> On Wed, 2019-01-09 at 15:29 +0100, Hans Verkuil wrote:
>> On 01/09/19 15:19, Paul Kocialkowski wrote:
>>> It was reported that some cases of interleaved video decoding require
>>> using the current destination buffer as a reference. However, this is
>>> no longer possible after the move to vb2_find_timestamp because only
>>> dequeued and done buffers are considered.
>>>
>>> Add a helper in our driver that also considers the current destination
>>> buffer before resorting to vb2_find_timestamp and use it in MPEG-2.
>>
>> This patch looks good, but can you also add checks to handle the case
>> when no buffer with the given timestamp was found? Probably should be done
>> in a third patch.
>>
>> I suspect the driver will crash if an unknown timestamp is passed on to the
>> driver. I would really like to see that corner case fixed.
>
> You're totally right and I think that more generarlly, the current code
> flow is rather fragile whenever something wrong happens in our setup()
> codec op. I think we should at least have that op return an error code
> and properly deal with it when that occurs.
>
> I am planning on making a cleanup series to fix that.
>
> Before using timestamps, reference buffer index validation was done in
> std_validate and now it's fully up to the driver. I wonder if it would
> be feasible to bring something back in there since all stateless
> drivers will face the same issue. The conditions set in
> cedrus_reference_index_find seem generic enough for that, but we should
> check that std_validate is not called too early, when the queue is in a
> different state (and the buffer might not be dequeud or done yet).
>
> What do you think?
I don't think you can do that. Say you queue a buffer that refers to a
ref frame F, and F is a buffer that's been dequeued. When std_validate is
called, this is fine and valid. Now later (but before the request is
processed) buffer F is queued by the application. Now F is no longer valid.
So when the driver processes the request, it won't be able to find F anymore.
A more interesting question is what you should do if a reference frame isn't
found. And should that be documented in the stateless decoder spec? (Or perhaps
it's there already, I'm not sure).
Regards,
Hans
>
> Cheers,
>
> Paul
>
>>> Signed-off-by: Paul Kocialkowski
>>> ---
>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 13 +
>>> drivers/staging/media/sunxi/cedrus/cedrus_dec.h | 2 ++
>>> drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c | 10 ++
>>> 3 files changed, 21 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> index 443fb037e1cf..2c295286766c 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
>>> @@ -22,6 +22,19 @@
>>> #include "cedrus_dec.h"
>>> #include "cedrus_hw.h"
>>>
>>> +int cedrus_reference_index_find(struct vb2_queue *queue,
>>> + struct vb2_buffer *vb2_buf, u64 timestamp)
>>> +{
>>> + /*
>>> +* Allow using the current capture buffer as reference, which can occur
>>> +* for field-coded pictures.
>>> +*/
>>> + if (vb2_buf->timestamp == timestamp)
>>> + return vb2_buf->index;
>>> + else
>>> + return vb2_find_timestamp(queue, timestamp, 0);
>>> +}
>>> +
>>> void cedrus_device_run(void *priv)
>>> {
>>> struct cedrus_ctx *ctx = priv;
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
>>> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
>>> index d1ae7903677b..8d0fc248220f 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
>>> @@ -16,6 +16,8 @@
>>> #ifndef _CEDRUS_DEC_H_
>>> #define _CEDRUS_DEC_H_
>>>
>>> +int cedrus_reference_index_find(struct vb2_queue *queue,
>>> + struct vb2_buffer *vb2_buf, u64 timestamp);
>>> void cedrus_device_run(void *priv);
>>>
>>> #endif
>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
>>> b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
>>> index cb45fda9aaeb..81c66a8aa1ac 100644
>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
>>> @@ -10,6 +10,7 @@
>>> #include
>>>
>>> #include "cedrus.h"
>>> +#include "cedrus_dec.h"
>>> #include "cedrus_hw.h"
>>> #include "cedrus_regs.h"
>>>
>>> @@ -159,8 +160,8 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
>>> struct cedrus_run *run)
>>> cedrus_write(dev, VE_DEC_MPEG_PICBOUNDSIZE, reg);
>>>
>>> /* Forward and backward prediction reference buffers. */
>>> - forward_idx = vb2_find_timestamp(cap_q,
>>> -slice_params->forward_ref_ts, 0);
>>> + forward_idx =
[linux-sunxi] Re: [PATCH 0/5] ARM: dts: sunxi: Enable Broadcom-based Bluetooth w/ serdev
On Wed, Jan 09, 2019 at 11:02:52PM +0800, Chen-Yu Tsai wrote: > Hi everyone, > > This is the second batch of patches enabling Bluetooth for Broadcom > (AMPAK) modules using the new serdev bindings. > > The patches are self-explanatory, so I won't go into the details here. > > This pretty much covers all the boards I have that have AMPAK modules. > The only ones missing are the A80-based boards, which I haven't gotten > working yet. Applied, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] [PATCH 0/5] ARM: dts: sunxi: Enable Broadcom-based Bluetooth w/ serdev
Hi everyone, This is the second batch of patches enabling Bluetooth for Broadcom (AMPAK) modules using the new serdev bindings. The patches are self-explanatory, so I won't go into the details here. This pretty much covers all the boards I have that have AMPAK modules. The only ones missing are the A80-based boards, which I haven't gotten working yet. Chen-Yu Tsai (5): ARM: dts: sun8i: r40: Add pinmux settings for UART3 on PG pingroup ARM: dts: sun8i: r40: Add pinmux setting for CLK_OUT_A ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix WiFi regulator definitions ARM: dts: sun8i: r40: bananapi-m2-ultra: Add Bluetooth device node ARM: dts: sunxi: bananapi-m2-plus: Add Bluetooth device node .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 41 +++ arch/arm/boot/dts/sun8i-r40.dtsi | 15 +++ arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 16 +++- 3 files changed, 71 insertions(+), 1 deletion(-) -- 2.20.1 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 5/5] ARM: dts: sunxi: bananapi-m2-plus: Add Bluetooth device node
The AP6212 is based on the Broadcom BCM43430 or BCM43438. The WiFi side
identifies as BCM43430, while the Bluetooth side identifies as BCM43438.
The Bluetooth side is connected to UART1 in a 4 wire configuration. Same
as the WiFi side, due to being the same chip and package, the board's
fixed 3.3V power regulator provides overall power via VBAT and I/O power
via VDDIO. The RTC clock output from the SoC provides the LPO low power
clock at 32.768 kHz.
This patch enables Bluetooth on this board, and also adds the missing
LPO clock on the WiFi side. There is also a PCM connection for
Bluetooth, but this is not covered here.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
b/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
index b3283aeb5b7d..3bed375b9c03 100644
--- a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
+++ b/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
@@ -103,6 +103,8 @@
compatible = "mmc-pwrseq-simple";
pinctrl-names = "default";
reset-gpios = <_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
+ clocks = < 1>;
+ clock-names = "ext_clock";
};
};
@@ -215,7 +217,19 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins>, <_rts_cts_pins>;
- status = "okay";
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = < 1>;
+ clock-names = "lpo";
+ vbat-supply = <_vcc3v3>;
+ vddio-supply = <_vcc3v3>;
+ device-wakeup-gpios = < 6 13 GPIO_ACTIVE_HIGH>; /* PG13 */
+ host-wakeup-gpios = < 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
+ shutdown-gpios = < 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+ };
};
_otg {
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 4/5] ARM: dts: sun8i: r40: bananapi-m2-ultra: Add Bluetooth device node
The AP6212 is based on the Broadcom BCM43430 or BCM43438. The WiFi side
identifies as BCM43430, while the Bluetooth side identifies as BCM43438.
The Bluetooth side is connected to UART3 in a 4 wire configuration. Same
as the WiFi side, due to being the same chip and package, DLDO1 and
DLDO2 regulator outputs from the PMIC provide overall power via VBAT and
I/O power via VDDIO. The CLK_OUT_A clock output from the SoC provides
the LPO low power clock at 32.768 kHz.
This patch enables Bluetooth on this board, and also adds the missing
LPO clock on the WiFi side. There is also a PCM connection for
Bluetooth, but this is not covered here.
The LPO clock is fed from CLK_OUT_A, which needs to be muxed on pin
PI12. This can be represented in multiple ways. This patch puts the
pinctrl property in the pin controller node. This is due to limitations
in Linux, where pinmux settings, even the same one, can not be shared
by multiple devices. Thus we cannot put it in both the WiFi and
Bluetooth device nodes. Putting it the CCU node is another option, but
Linux's CCU driver does not handle pinctrl. Also the pin controller is
guaranteed to be initialized after the CCU, when clocks are available.
And any other devices that use muxed pins are guaranteed to be
initialized after the pin controller. Thus having the CLK_OUT_A pinmux
reference be in the pin controller node is a good choice without having
to deal with implementation issues.
Signed-off-by: Chen-Yu Tsai
---
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 26 +++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 1a6794e63b90..c488aaacbd68 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -102,6 +102,8 @@
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = < 6 10 GPIO_ACTIVE_LOW>; /* PG10 WIFI_EN */
+ clocks = < CLK_OUTA>;
+ clock-names = "ext_clock";
};
};
@@ -196,6 +198,11 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_out_a_pin>;
+};
+
_aldo2 {
regulator-always-on;
regulator-min-microvolt = <250>;
@@ -293,6 +300,25 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pg_pins>, <_rts_cts_pg_pins>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = < CLK_OUTA>;
+ clock-names = "lpo";
+ vbat-supply = <_dldo2>;
+ vddio-supply = <_dldo1>;
+ device-wakeup-gpios = < 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
+ /* TODO host wake line connected to PMIC GPIO pins */
+ shutdown-gpios = < 7 12 GPIO_ACTIVE_HIGH>; /* PH12 */
+ max-speed = <150>;
+ };
+};
+
{
usb1_vbus-supply = <_vcc5v0>;
usb2_vbus-supply = <_vcc5v0>;
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3/5] ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix WiFi regulator definitions
The design of the Bananapi M2 Ultra has both DLDO1 and DLDO2 regulators
provide power to the WiFi+BT module, which is based on the Broadcom
BCM43438 or BCM43430 chip. Each regulator output from the PMIC can supply
up to 200 mA. The datasheet of the chip suggests a maximum power draw of
up to 360 mA when transmitting, thus requiring two outputs from the PMIC
to handle the load. However the device tree only references one of them,
leaving the other unused and possibly turned off.
This patch marks both as always-on, since we don't have a proper binding
to specify two regulators as "bound together". The name and constraints
of DLDO2 are also added.
Fixes: da7ac948fa93 ("ARM: dts: sun8i: Add board dts file for Banana Pi M2
Ultra")
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 438b7b44dab3..1a6794e63b90 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -250,12 +250,27 @@
regulator-name = "vcc-wifi-io";
};
+/*
+ * Our WiFi chip needs both DLDO2 and DLDO3 to be powered at the same
+ * time, with the two being in sync, to be able to meet maximum power
+ * consumption during transmits. Since this is not really supported
+ * right now, just use the two as always on, and we will fix it later.
+ */
+
_dldo2 {
+ regulator-always-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vcc-wifi";
};
+_dldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-wifi-2";
+};
+
_dldo4 {
regulator-min-microvolt = <250>;
regulator-max-microvolt = <250>;
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/5] ARM: dts: sun8i: r40: Add pinmux setting for CLK_OUT_A
CLK_OUT_A, an external clock output function driven from the clock
control unit, on the R40 is sometimes used to provide a low rate low
power clock to a WiFi or Bluetooth controller.
This patch adds a pinmux setting for it.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-r40.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index f1fcfa0bdce0..06b685869f52 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -342,6 +342,11 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
+ clk_out_a_pin: clk-out-a-pin {
+ pins = "PI12";
+ function = "clk_out_a";
+ };
+
gmac_rgmii_pins: gmac-rgmii-pins {
pins = "PA0", "PA1", "PA2", "PA3",
"PA4", "PA5", "PA6", "PA7",
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 1/5] ARM: dts: sun8i: r40: Add pinmux settings for UART3 on PG pingroup
UART3 on the PG pingroup on the R40 SoC is commonly used to connect the
bluetooth controller in a WiFi+Bluetooth combo chip, with the WiFi bits
also on the PG pingroup.
This patch adds two device nodes for UART3 on PG pingroup, one for the
RX/TX pins, and one for the RTS/CTS pins. Consumers can reference either
just the RX/TX pinmux setting or both, depending on the application.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-r40.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 89762dbefe42..f1fcfa0bdce0 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -389,6 +389,16 @@
pins = "PB22", "PB23";
function = "uart0";
};
+
+ uart3_pg_pins: uart3-pg-pins {
+ pins = "PG6", "PG7";
+ function = "uart3";
+ };
+
+ uart3_rts_cts_pg_pins: uart3-rts-cts-pg-pins {
+ pins = "PG8", "PG9";
+ function = "uart3";
+ };
};
wdt: watchdog@1c20c90 {
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/2] media: cedrus: Allow using the current dst buffer as reference
Hi,
On Wed, 2019-01-09 at 15:29 +0100, Hans Verkuil wrote:
> On 01/09/19 15:19, Paul Kocialkowski wrote:
> > It was reported that some cases of interleaved video decoding require
> > using the current destination buffer as a reference. However, this is
> > no longer possible after the move to vb2_find_timestamp because only
> > dequeued and done buffers are considered.
> >
> > Add a helper in our driver that also considers the current destination
> > buffer before resorting to vb2_find_timestamp and use it in MPEG-2.
>
> This patch looks good, but can you also add checks to handle the case
> when no buffer with the given timestamp was found? Probably should be done
> in a third patch.
>
> I suspect the driver will crash if an unknown timestamp is passed on to the
> driver. I would really like to see that corner case fixed.
You're totally right and I think that more generarlly, the current code
flow is rather fragile whenever something wrong happens in our setup()
codec op. I think we should at least have that op return an error code
and properly deal with it when that occurs.
I am planning on making a cleanup series to fix that.
Before using timestamps, reference buffer index validation was done in
std_validate and now it's fully up to the driver. I wonder if it would
be feasible to bring something back in there since all stateless
drivers will face the same issue. The conditions set in
cedrus_reference_index_find seem generic enough for that, but we should
check that std_validate is not called too early, when the queue is in a
different state (and the buffer might not be dequeud or done yet).
What do you think?
Cheers,
Paul
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 13 +
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.h | 2 ++
> > drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c | 10 ++
> > 3 files changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > index 443fb037e1cf..2c295286766c 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -22,6 +22,19 @@
> > #include "cedrus_dec.h"
> > #include "cedrus_hw.h"
> >
> > +int cedrus_reference_index_find(struct vb2_queue *queue,
> > + struct vb2_buffer *vb2_buf, u64 timestamp)
> > +{
> > + /*
> > +* Allow using the current capture buffer as reference, which can occur
> > +* for field-coded pictures.
> > +*/
> > + if (vb2_buf->timestamp == timestamp)
> > + return vb2_buf->index;
> > + else
> > + return vb2_find_timestamp(queue, timestamp, 0);
> > +}
> > +
> > void cedrus_device_run(void *priv)
> > {
> > struct cedrus_ctx *ctx = priv;
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
> > index d1ae7903677b..8d0fc248220f 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
> > @@ -16,6 +16,8 @@
> > #ifndef _CEDRUS_DEC_H_
> > #define _CEDRUS_DEC_H_
> >
> > +int cedrus_reference_index_find(struct vb2_queue *queue,
> > + struct vb2_buffer *vb2_buf, u64 timestamp);
> > void cedrus_device_run(void *priv);
> >
> > #endif
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
> > index cb45fda9aaeb..81c66a8aa1ac 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
> > @@ -10,6 +10,7 @@
> > #include
> >
> > #include "cedrus.h"
> > +#include "cedrus_dec.h"
> > #include "cedrus_hw.h"
> > #include "cedrus_regs.h"
> >
> > @@ -159,8 +160,8 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
> > struct cedrus_run *run)
> > cedrus_write(dev, VE_DEC_MPEG_PICBOUNDSIZE, reg);
> >
> > /* Forward and backward prediction reference buffers. */
> > - forward_idx = vb2_find_timestamp(cap_q,
> > -slice_params->forward_ref_ts, 0);
> > + forward_idx = cedrus_reference_index_find(cap_q, >dst->vb2_buf,
> > + slice_params->forward_ref_ts);
> >
> > fwd_luma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 0);
> > fwd_chroma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 1);
> > @@ -168,8 +169,9 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
> > struct cedrus_run *run)
> > cedrus_write(dev, VE_DEC_MPEG_FWD_REF_LUMA_ADDR, fwd_luma_addr);
> > cedrus_write(dev, VE_DEC_MPEG_FWD_REF_CHROMA_ADDR, fwd_chroma_addr);
> >
> > - backward_idx = vb2_find_timestamp(cap_q,
> > - slice_params->backward_ref_ts, 0);
> > + backward_idx = cedrus_reference_index_find(cap_q,
[linux-sunxi] Re: [PATCH 2/2] media: cedrus: Allow using the current dst buffer as reference
On 01/09/19 15:19, Paul Kocialkowski wrote:
> It was reported that some cases of interleaved video decoding require
> using the current destination buffer as a reference. However, this is
> no longer possible after the move to vb2_find_timestamp because only
> dequeued and done buffers are considered.
>
> Add a helper in our driver that also considers the current destination
> buffer before resorting to vb2_find_timestamp and use it in MPEG-2.
This patch looks good, but can you also add checks to handle the case
when no buffer with the given timestamp was found? Probably should be done
in a third patch.
I suspect the driver will crash if an unknown timestamp is passed on to the
driver. I would really like to see that corner case fixed.
Regards,
Hans
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 13 +
> drivers/staging/media/sunxi/cedrus/cedrus_dec.h | 2 ++
> drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c | 10 ++
> 3 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index 443fb037e1cf..2c295286766c 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -22,6 +22,19 @@
> #include "cedrus_dec.h"
> #include "cedrus_hw.h"
>
> +int cedrus_reference_index_find(struct vb2_queue *queue,
> + struct vb2_buffer *vb2_buf, u64 timestamp)
> +{
> + /*
> + * Allow using the current capture buffer as reference, which can occur
> + * for field-coded pictures.
> + */
> + if (vb2_buf->timestamp == timestamp)
> + return vb2_buf->index;
> + else
> + return vb2_find_timestamp(queue, timestamp, 0);
> +}
> +
> void cedrus_device_run(void *priv)
> {
> struct cedrus_ctx *ctx = priv;
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
> b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
> index d1ae7903677b..8d0fc248220f 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
> @@ -16,6 +16,8 @@
> #ifndef _CEDRUS_DEC_H_
> #define _CEDRUS_DEC_H_
>
> +int cedrus_reference_index_find(struct vb2_queue *queue,
> + struct vb2_buffer *vb2_buf, u64 timestamp);
> void cedrus_device_run(void *priv);
>
> #endif
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
> index cb45fda9aaeb..81c66a8aa1ac 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
> @@ -10,6 +10,7 @@
> #include
>
> #include "cedrus.h"
> +#include "cedrus_dec.h"
> #include "cedrus_hw.h"
> #include "cedrus_regs.h"
>
> @@ -159,8 +160,8 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
> struct cedrus_run *run)
> cedrus_write(dev, VE_DEC_MPEG_PICBOUNDSIZE, reg);
>
> /* Forward and backward prediction reference buffers. */
> - forward_idx = vb2_find_timestamp(cap_q,
> - slice_params->forward_ref_ts, 0);
> + forward_idx = cedrus_reference_index_find(cap_q, >dst->vb2_buf,
> + slice_params->forward_ref_ts);
>
> fwd_luma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 0);
> fwd_chroma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 1);
> @@ -168,8 +169,9 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
> struct cedrus_run *run)
> cedrus_write(dev, VE_DEC_MPEG_FWD_REF_LUMA_ADDR, fwd_luma_addr);
> cedrus_write(dev, VE_DEC_MPEG_FWD_REF_CHROMA_ADDR, fwd_chroma_addr);
>
> - backward_idx = vb2_find_timestamp(cap_q,
> - slice_params->backward_ref_ts, 0);
> + backward_idx = cedrus_reference_index_find(cap_q, >dst->vb2_buf,
> +
> slice_params->backward_ref_ts);
> +
> bwd_luma_addr = cedrus_dst_buf_addr(ctx, backward_idx, 0);
> bwd_chroma_addr = cedrus_dst_buf_addr(ctx, backward_idx, 1);
>
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/2] media: cedrus: Allow using the current dst buffer as reference
It was reported that some cases of interleaved video decoding require
using the current destination buffer as a reference. However, this is
no longer possible after the move to vb2_find_timestamp because only
dequeued and done buffers are considered.
Add a helper in our driver that also considers the current destination
buffer before resorting to vb2_find_timestamp and use it in MPEG-2.
Signed-off-by: Paul Kocialkowski
---
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 13 +
drivers/staging/media/sunxi/cedrus/cedrus_dec.h | 2 ++
drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c | 10 ++
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index 443fb037e1cf..2c295286766c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -22,6 +22,19 @@
#include "cedrus_dec.h"
#include "cedrus_hw.h"
+int cedrus_reference_index_find(struct vb2_queue *queue,
+ struct vb2_buffer *vb2_buf, u64 timestamp)
+{
+ /*
+* Allow using the current capture buffer as reference, which can occur
+* for field-coded pictures.
+*/
+ if (vb2_buf->timestamp == timestamp)
+ return vb2_buf->index;
+ else
+ return vb2_find_timestamp(queue, timestamp, 0);
+}
+
void cedrus_device_run(void *priv)
{
struct cedrus_ctx *ctx = priv;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
index d1ae7903677b..8d0fc248220f 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h
@@ -16,6 +16,8 @@
#ifndef _CEDRUS_DEC_H_
#define _CEDRUS_DEC_H_
+int cedrus_reference_index_find(struct vb2_queue *queue,
+ struct vb2_buffer *vb2_buf, u64 timestamp);
void cedrus_device_run(void *priv);
#endif
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
index cb45fda9aaeb..81c66a8aa1ac 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c
@@ -10,6 +10,7 @@
#include
#include "cedrus.h"
+#include "cedrus_dec.h"
#include "cedrus_hw.h"
#include "cedrus_regs.h"
@@ -159,8 +160,8 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
struct cedrus_run *run)
cedrus_write(dev, VE_DEC_MPEG_PICBOUNDSIZE, reg);
/* Forward and backward prediction reference buffers. */
- forward_idx = vb2_find_timestamp(cap_q,
-slice_params->forward_ref_ts, 0);
+ forward_idx = cedrus_reference_index_find(cap_q, >dst->vb2_buf,
+ slice_params->forward_ref_ts);
fwd_luma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 0);
fwd_chroma_addr = cedrus_dst_buf_addr(ctx, forward_idx, 1);
@@ -168,8 +169,9 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx,
struct cedrus_run *run)
cedrus_write(dev, VE_DEC_MPEG_FWD_REF_LUMA_ADDR, fwd_luma_addr);
cedrus_write(dev, VE_DEC_MPEG_FWD_REF_CHROMA_ADDR, fwd_chroma_addr);
- backward_idx = vb2_find_timestamp(cap_q,
- slice_params->backward_ref_ts, 0);
+ backward_idx = cedrus_reference_index_find(cap_q, >dst->vb2_buf,
+
slice_params->backward_ref_ts);
+
bwd_luma_addr = cedrus_dst_buf_addr(ctx, backward_idx, 0);
bwd_chroma_addr = cedrus_dst_buf_addr(ctx, backward_idx, 1);
--
2.20.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 1/2] media: cedrus: Cleanup duplicate declarations from cedrus_dec header
Some leftover declarations are still in the cedrus_dec header although they were moved to cedrus_video already. Clean them up. Signed-off-by: Paul Kocialkowski --- drivers/staging/media/sunxi/cedrus/cedrus_dec.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h index 4f423d3a1cad..d1ae7903677b 100644 --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.h +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.h @@ -16,12 +16,6 @@ #ifndef _CEDRUS_DEC_H_ #define _CEDRUS_DEC_H_ -extern const struct v4l2_ioctl_ops cedrus_ioctl_ops; - -void cedrus_device_work(struct work_struct *work); void cedrus_device_run(void *priv); -int cedrus_queue_init(void *priv, struct vb2_queue *src_vq, - struct vb2_queue *dst_vq); - #endif -- 2.20.1 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] u-boot: MMC broken on Linksprite A10/A20 boards in 2018.11
On Wed, Jan 9, 2019 at 1:08 AM Priit Laes wrote: > > On Tue, Jan 08, 2019 at 11:54:32PM +0530, Jagan Teki wrote: > > On Thu, Jan 3, 2019 at 9:33 PM Zoltan HERPAI wrote: > > > > > > Hi Jagan, Adam, > > > > > > On Thu, 3 Jan 2019, Jagan Teki wrote: > > > > > > > On Thu, Jan 3, 2019 at 6:57 PM Zoltan HERPAI wrote: > > > >> > > > >> Hi all, > > > >> > > > >> The DTS resync between 2018.09 and 2018.11 seems to have broken the MMC > > > >> support for the Linksprite pcDuino (A10) and pcDuino v3 (A20) boards. > > > >> The resync happened in b9d59d0 [1] and 3c92cca [2], after which u-boot > > > >> doesn't recognize the MMC controller and freezes the board (exactly the > > > >> same happens on the v3 board). > > > >> > > > >> CUT HERE > > > >> U-Boot SPL 2018.11 (Dec 31 2018 - 14:36:52 +) > > > >> DRAM: 1024 MiB > > > >> CPU: 100800Hz, AXI/AHB/APB: 3/2/2 > > > >> Trying to boot from MMC1 > > > >> > > > >> > > > >> U-Boot 2018.11 (Dec 31 2018 - 14:36:52 +) Allwinner Technology > > > >> > > > >> CPU: Allwinner A10 (SUN4I) > > > >> Model: LinkSprite pcDuino > > > >> I2C: ready > > > >> DRAM: 1 GiB > > > >> MMC: > > > >> CUT HERE > > > >> > > > >> Reverting these commits solve the problem and the boards boot > > > >> correctly. > > > >> Initially I thought this might be due to removing the > > > >> mmc0_cd_pin_reference_design (syncing that from the kernel into > > > >> u-boot), > > > >> which was discussed here [3] and was considered as a move that might > > > >> break MMC on some boards, but re-adding that reference pin only in the > > > >> pcduino DTSes did not resolve the freeze. > > > >> > > > >> Questions: > > > >> - A similar board - where the reference pin is used for CD - is the > > > >> Cubieboard 2. Can someone test 2018.11 on it to see if it freezes as > > > >> well? Out of A20, I have a Bananapro, but that's using a non-reference > > > >> pin for CD, and boots fine. > > > > > > > > A10, enable DM_MMC so it can effect DT. or enable > > > > CONFIG_MMC0_CD_PIN="PH1" > > > > > > > > Added Adam, (who actually tested DM_MMC on A10) > > > > > > I tested with "either" and "both", neither worked - see below. Along with > > > CONFIG_DM_MMC, I've also enabled CONFIG_DM_DEBUG to see what's happening - > > > here is the output: > > > > > > [...] > > > MMC: uclass_find_device_by_seq: 0 0 > > > - -1 -1 'mmc@1c0f000' > > > - not found > > > uclass_find_device_by_seq: 1 0 > > > - -1 -1 'mmc@1c0f000' > > > - not found > > > uclass_find_device_by_seq: 0 -1 > > > uclass_find_device_by_seq: 0 0 > > > - -1 -1 'mmc@1c0f000' > > > - not found > > > Entering sunxi_mmc_probe > > > ofnode_read_u32: bus-width: 0x4 (4) > > > sunxi_mmc: priv->reg: 1c0f000 > > > sunxi_mmc: priv->mclkreg: 1c2 > > > > I'm looking for gate and clk register values, print at the end of probe > > 1c2 + 0x60 > > 1c2 + 0x88 > > With current master: > sunxi_mmc_probe: gate_reg: 0x4141 > sunxi_mmc_probe: clk_reg: 0x0 Please check this gist [1] [1] https://gist.github.com/openedev/e76ef26f75f133883f295225efb5b4bd -- You received this message because you are subscribed to the Google 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] ARM: dts: sun8i: h3: Add ethernet0 alias to Beelink X2
On Wed, Jan 09, 2019 at 06:13:24PM +0800, Chen-Yu Tsai wrote: > On Wed, Jan 9, 2019 at 6:12 PM Maxime Ripard > wrote: > > > > On Tue, Jan 08, 2019 at 08:18:40PM +0100, Jernej Skrabec wrote: > > > Because "ethernet0" alias is missing, U-Boot doesn't generate board > > > specific MAC address. Effect of this is random MAC address every boot > > > and thus new IP address is assigned to the board. > > > > > > Fix this by adding alias. > > > > > > Signed-off-by: Jernej Skrabec > > > > Applied, thanks! > > Maxime > > Might we add a fixes tag, so the patch gets backported? It's done, thanks for the suggestion! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH] ARM: dts: sun8i: h3: Add ethernet0 alias to Beelink X2
On Wed, Jan 9, 2019 at 6:12 PM Maxime Ripard wrote: > > On Tue, Jan 08, 2019 at 08:18:40PM +0100, Jernej Skrabec wrote: > > Because "ethernet0" alias is missing, U-Boot doesn't generate board > > specific MAC address. Effect of this is random MAC address every boot > > and thus new IP address is assigned to the board. > > > > Fix this by adding alias. > > > > Signed-off-by: Jernej Skrabec > > Applied, thanks! > Maxime Might we add a fixes tag, so the patch gets backported? ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] ARM: dts: sun8i: h3: Add ethernet0 alias to Beelink X2
On Tue, Jan 08, 2019 at 08:18:40PM +0100, Jernej Skrabec wrote: > Because "ethernet0" alias is missing, U-Boot doesn't generate board > specific MAC address. Effect of this is random MAC address every boot > and thus new IP address is assigned to the board. > > Fix this by adding alias. > > Signed-off-by: Jernej Skrabec Applied, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
