* [linux-sunxi] [PATCH v5 0/7] ARM: ASoC: drm: sun8i: Add DE2 HDMI audio and video
From: Jean-Francois Moine @ 2016-10-23 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64fgJShfyEHnjm6ryg00WhHkmnPj+FdjHcXBa6HQbyTuA@mail.gmail.com>
On Sun, 23 Oct 2016 09:38:04 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> > Recently, an announce about Tina OS for the R series
> > https://www.youtube.com/watch?v=h7KD-6HblAU
> > was followed by the upload of a new linux-3.4 source tree
> > https://github.com/tinalinux/linux-3.4
> > with files containing GPL headers.
> >
> > Well, I don't know if these sources are really from Allwinner, but
> > anyway, this is the opportunity to propose a new version of my DRM
> > HDMI driver.
>
> Could you clarify about this bit? Did you just clean up Allwinner's
> existing drivers? Or just use them as reference? Either way I think
> this deserves some mention in all your copyright headers.
>
> Otherwise what difference does the new release make?
- Allwinner's video driver is not DRM.
- their driver has no hardware cursor nor video overlay.
- I wrote the video DRM driver from the document
Allwinner_H3_Datasheet_V1.2.pdf
and the structures defined in
linux-3.4/drivers/video/sunxi/disp2/disp/de/lowlevel_sun8iw7/de_rtmx.h
Reading Allwinner's code helped me to understand how the DE2
is working.
- my lowlevel HDMI is just a cleanup of theirs with explanations
about the registers. Magic constants remain due to the lack of
knowledge about the PHYs.
- the mention of Allwinner in the copyright headers is needed to
indicate the source of the structures (DE2) and code (HDMI).
The main difference is the DRM interface and the use of the EDID,
permitting dynamic video resolution change with xrandr.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Jean-Francois Moine @ 2016-10-23 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67gDd650TJk_-oHOehnzdH2qor=36HXdPt339Ji=ToAMg@mail.gmail.com>
On Sun, 23 Oct 2016 09:33:16 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> > Note: This driver is closed to the sun4i-i2s except that:
> > - it handles the H3
>
> If it's close to sun4i-i2s, you should probably rework that one to support
> the newer SoCs.
>
> > - it creates the sound card (with sun4i-i2s, the sound card is created
> > by the CODECs)
>
> I think this is wrong. I2S is only the DAI. You typically have a separate
> platform driver for the whole card, or just use simple-card.
An other device is not needed. The layout is simple:
I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
The HDMI CODEC is supported by the HDMI video driver (only one device),
so, it cannot be the card device.
ASoC does not use the CPU DAI device (I2S_controller), so, it is
natural to use it to handle the card.
Otherwise, the simple-card asks for a node definition in the DT and
this node is a pure Linux software entity. On the other side, the
simple-graph-card from Kuninori is not useful for this simple case.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3
From: LABBE Corentin @ 2016-10-23 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020203654.2erph2mr73yzksla@lukather>
On Thu, Oct 20, 2016 at 10:36:54PM +0200, Maxime Ripard wrote:
> On Wed, Oct 19, 2016 at 09:40:16AM +0200, LABBE Corentin wrote:
> > On Wed, Oct 05, 2016 at 12:21:30PM +0200, Jean-Francois Moine wrote:
> > > On Wed, 5 Oct 2016 11:48:24 +0200
> > > Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> > >
> > > > This patch add support for the sunxi-sid driver to the device tree for sun8i-h3.
> > > >
> > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > ---
> > > > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > index 9f58bb4..abfd29c 100644
> > > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > @@ -211,6 +211,11 @@
> > > > #size-cells = <0>;
> > > > };
> > > >
> > > > + sid: eeprom at 01c14200 {
> > > > + compatible = "allwinner,sun7i-a20-sid";
> > > > + reg = <0x01c14200 0x200>;
> > >
> > > The datasheet says 1Kb starting at 0x01c14000.
> > > Is there any reason to reduce the area and to shift the offset?
> > >
> >
> > According to http://linux-sunxi.org/SID_Register_Guide "For
> > Allwinner A83T and H3 the SID address space starts at 0x01c14000,
> > and the e-fuses are at offset 0x200".
> >
> > So I use this offset, since the sunxi_sid driver need the base
> > address of e-fuses.
> >
> > The easiest solution is to use 0x01c14200 since the other part of
> > sid is not used and not known (A83T/H3 user manual doesnt give any
> > information on all sid space, worse for A64 which reference SID only
> > in memory map).
> >
> > So probably for H3/A64/A83T, there will never any usage of the rest
> > of the SID address space.
>
> And since we can't know that, and we have to maintain the DT ABI,
> using the whole address map and an offset, with a new compatible, is
> definetely the safest thing to do.
>
I have two way of doing it, which one do you prefer ?
- Adding two optionnal properties: efuses-offset and efuses-size defaulting to 0 and resourcesize.
- Adding a subnode called efuses with its own reg=<>
The first one is easy and didnt need any work on previous DT entries.
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH v4 01/10] ethernet: add sun8i-emac driver
From: LABBE Corentin @ 2016-10-23 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475852559.1945.2.camel@perches.com>
On Fri, Oct 07, 2016 at 08:02:39AM -0700, Joe Perches wrote:
> On Fri, 2016-10-07 at 10:25 +0200, Corentin Labbe wrote:
> > This patch add support for sun8i-emac ethernet MAC hardware.
> > It could be found in Allwinner H3/A83T/A64 SoCs.
>
> trivial notes:
>
> > diff --git a/drivers/net/ethernet/allwinner/sun8i-emac.c b/drivers/net/ethernet/allwinner/sun8i-emac.c
> []
> > +static const char const estats_str[][ETH_GSTRING_LEN] = {
>
> one too many const
>
> > +/* MAGIC value for knowing if a descriptor is available or not */
> > +#define DCLEAN cpu_to_le32(BIT(16) | BIT(14) | BIT(12) | BIT(10) | BIT(9))
>
> Aren't there #defines for these bits?
>
> > +static void sun8i_emac_flow_ctrl(struct sun8i_emac_priv *priv, int duplex,
> > + int fc)
> > +{
> > + u32 flow = 0;
> > +
> > + flow = readl(priv->base + EMAC_RX_CTL0);
> > + if (fc & EMAC_FLOW_RX)
> > + flow |= BIT(16);
> > + else
> > + flow &= ~BIT(16);
> > + writel(flow, priv->base + EMAC_RX_CTL0);
> > +
> > + flow = readl(priv->base + EMAC_TX_FLOW_CTL);
> > + if (fc & EMAC_FLOW_TX)
> > + flow |= BIT(0);
> > + else
> > + flow &= ~BIT(0);
>
> more magic bits that could be #defines
>
> > +static int sun8i_emac_rx_from_ddesc(struct net_device *ndev, int i)
> > +{
> > []
> > + /* the checksum or length of received frame's payload is wrong*/
> > + if (dstatus & BIT(0)) {
> []
> > + if (dstatus & BIT(1)) {
> []
> > + if ((dstatus & BIT(3))) {
>
> etc...
Thanks for the review, I will fix all thoses issue.
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Hanjun Guo @ 2016-10-23 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1941586c-4c51-60d8-a77a-ad56fe5f3e3f@codeaurora.org>
Hi Harb,
On 2016/10/20 0:59, Abdulhamid, Harb wrote:
> On 10/18/2016 8:44 AM, Hanjun Guo wrote:
>> Hi Tyler,
>>
>> On 2016/10/8 5:31, Tyler Baicar wrote:
>>> ARM APEI extension proposal added SEA (Synchrounous External
>>> Abort) notification type for ARMv8.
>>> Add a new GHES error source handling function for SEA. If an error
>>> source's notification type is SEA, then this function can be registered
>>> into the SEA exception handler. That way GHES will parse and report
>>> SEA exceptions when they occur.
>> Does this SEA is replayed by the firmware (firmware first handling)
>> or directly triggered by the hardware when error is happened?
> Architecturally, an SEA must be synchronous and *precise*, so if you
> take an SEA on a particular load instruction, firmware/hardware should
> not be corrupting the context/state of the PE to allow software to
> determine which thread/process encountered the abort. GHES error status
That's my concern too, and that's why I raised my question :)
> block will be expose to software with information about the type,
> severity, physical address impacted.
>
> Generally the error status block is populated by firmware. However, as
> long as the above requirement is met, I don't think the spec precludes
> error status block being populated by hardware. Those details must be
> completely transparent to software.
>
> Finally, to answer your more specific question: If the implementation
> of firmware-first involves trapping the SEA in EL3 to do some firmware
> first handling, firmware must maintain the context of the offending ELx,
> generate an error record, and then "replay" the exception to normal
> (non-secure) software at the appropriate vector base address.
>
Thank you for your answer, it clears my confusion now, I will try something
similar on ARM64 platform, will get back to you if I get blocks.
Thanks
Hanjun
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Stefan Wahren @ 2016-10-23 9:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
i'm faced with the issue that on i.MX28 the console is unable to wake up from
freeze ( suspend to idle). I tested it with Linux 4.9-rc1, 4.8 and 3.18 (
cmdline has
no_console_suspend=1 ) and also with a i.MX23 with the same result. The suspend
seems to work, but there is no reaction to the console after the freeze except
an hung task warning after some time:
echo freeze > /sys/power/state
Strangely the suspend to RAM from console works without any issues:
echo mem > /sys/power/state
Any ideas what could be the problem?
Here is the console output:
root at duckbill:~# echo mem > /sys/power/state
[ 44.881170] PM: Syncing filesystems ... [ 49.726565] done.
[ 49.787188] Freezing user space processes ... (elapsed 0.008 seconds) done.
[ 49.803455] Freezing remaining freezable tasks ... (elapsed 0.004 seconds)
done.
[ 50.553231] PM: suspend of devices complete after 731.338 msecs
[ 50.566850] PM: late suspend of devices complete after 7.436 msecs
[ 50.581416] PM: noirq suspend of devices complete after 8.124 msecs
[ 50.598957] PM: noirq resume of devices complete after 10.888 msecs
[ 50.615757] PM: early resume of devices complete after 7.115 msecs
[ 50.641481] Suspended for 1.283 seconds
[ 50.646424] PM: resume of devices complete after 24.225 msecs
[ 50.660304] Restarting tasks ... [ 50.706421] done.
root at duckbill:~# echo freeze > /sys/power/state
[ 64.701251] PM: Syncing filesystems ... [ 65.992083] done.
[ 66.014271] Freezing user space processes ... (elapsed 0.004 seconds) done.
[ 66.026151] Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
done.
[ 66.204858] PM: suspend of devices complete after 163.009 msecs
[ 66.218808] PM: late suspend of devices complete after 7.762 msecs
[ 66.232985] PM: noirq suspend of devices complete after 7.887 msecs
[ 192.228595] random: crng init done
[ 243.817366] INFO: task ext4lazyinit:69 blocked for more than 120 seconds.
[ 243.824216] Not tainted 4.9.0-rc1 #1
[ 243.828482] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 243.836359] ext4lazyinit D c05a9fdc 0 69 2 0x00000000
[ 243.843028] [<c05a9fdc>] (__schedule) from [<c05aa8e8>] (schedule+0x3c/0xbc)
[ 243.850292] [<c05aa8e8>] (schedule) from [<c05ae768>]
(schedule_timeout+0x23c/0x3d8)
[ 243.858247] [<c05ae768>] (schedule_timeout) from [<c05a9cc8>]
(io_schedule_timeout+0xb8/0x13c)
[ 243.866934] [<c05a9cc8>] (io_schedule_timeout) from [<c05ab308>]
(T.1434+0xac/0x12c)
[ 243.874884] [<c05ab308>] (T.1434) from [<c02c7304>]
(submit_bio_wait+0x50/0x68)
[ 243.882419] [<c02c7304>] (submit_bio_wait) from [<c02d96f4>]
(blkdev_issue_zeroout+0x174/0x1ec)
[ 243.891323] [<c02d96f4>] (blkdev_issue_zeroout) from [<c0196ae8>]
(ext4_init_inode_table+0x1ac/0x3b0)
[ 243.900753] [<c0196ae8>] (ext4_init_inode_table) from [<c01ba40c>]
(ext4_lazyinit_thread+0x280/0x398)
[ 243.910177] [<c01ba40c>] (ext4_lazyinit_thread) from [<c003bce4>]
(kthread+0xc4/0xe0)
[ 243.918213] [<c003bce4>] (kthread) from [<c000a34c>]
(ret_from_fork+0x14/0x28)
[ 243.925479]
[ 243.925479] Showing all locks held in the system:
[ 243.931849] 2 locks held by khungtaskd/10:
[ 243.935987] #0: [ 243.937869] (
rcu_read_lock[ 243.940746] ){......}
, at: [ 243.943624] [<c00936ac>] watchdog+0xb4/0x61c
[ 243.948054] #1: [ 243.949843] (
tasklist_lock[ 243.952700] ){.+.+..}
, at: [ 243.955576] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
[ 243.961074] 4 locks held by ext4lazyinit/69:
[ 243.965380] #0: [ 243.967273] (
&type->s_umount_key[ 243.970673] #22
){++++++}[ 243.973257] , at:
[ 243.975320] [<c01ba260>] ext4_lazyinit_thread+0xd4/0x398
[ 243.980776] #1: [ 243.982566] (
sb_writers[ 243.985167] #3
){.+.+.+}[ 243.987778] , at:
[ 243.989861] [<c01ba278>] ext4_lazyinit_thread+0xec/0x398
[ 243.995201] #2: [ 243.996973] (
jbd2_handle[ 243.999903] ){++++..}
, at: [ 244.002796] [<c01f62b8>] start_this_handle+0xec/0x404
[ 244.008014] #3: [ 244.009805] (
&meta_group_info[i]->alloc_sem[ 244.014141] ){++++..}
, at: [ 244.017138] [<c01969f4>] ext4_init_inode_table+0xb8/0x3b0
[ 244.022619] 4 locks held by bash/386:
[ 244.026306] #0: [ 244.028204] (
sb_writers[ 244.030825] #4
){.+.+.+}[ 244.033326] , at:
[ 244.035390] [<c011f470>] vfs_write+0x194/0x1a4
[ 244.039985] #1: [ 244.041772] (
&of->mutex[ 244.044374] ){+.+.+.}
, at: [ 244.047366] [<c018ff38>] kernfs_fop_write+0xc0/0x1d0
[ 244.052381] #2: [ 244.054154] (
s_active[ 244.056571] #44
){.+.+.+}[ 244.059289] , at:
[ 244.061364] [<c018ff40>] kernfs_fop_write+0xc8/0x1d0
[ 244.066354] #3: [ 244.068247] (
pm_mutex[ 244.070690] ){+.+.+.}
, at: [ 244.073576] [<c005b520>] pm_suspend+0x98/0x784
[ 244.078179]
[ 244.079713] =============================================
[ 244.079713]
[ 244.086660] INFO: task bash:386 blocked for more than 120 seconds.
[ 244.092998] Not tainted 4.9.0-rc1 #1
[ 244.097233] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 244.105109] bash D c05a9fdc 0 386 289 0x00000000
[ 244.111762] [<c05a9fdc>] (__schedule) from [<c05aa8e8>] (schedule+0x3c/0xbc)
[ 244.119028] [<c05aa8e8>] (schedule) from [<c005aee4>]
(suspend_devices_and_enter+0x480/0xa24)
[ 244.127771] [<c005aee4>] (suspend_devices_and_enter) from [<c005b8a8>]
(pm_suspend+0x420/0x784)
[ 244.136551] [<c005b8a8>] (pm_suspend) from [<c0059dd8>]
(state_store+0x80/0xcc)
[ 244.144075] [<c0059dd8>] (state_store) from [<c02efed0>]
(kobj_attr_store+0x18/0x1c)
[ 244.152030] [<c02efed0>] (kobj_attr_store) from [<c0190e54>]
(sysfs_kf_write+0x48/0x4c)
[ 244.160217] [<c0190e54>] (sysfs_kf_write) from [<c018ff74>]
(kernfs_fop_write+0xfc/0x1d0)
[ 244.168600] [<c018ff74>] (kernfs_fop_write) from [<c011f1e4>]
(__vfs_write+0x2c/0x124)
[ 244.176591] [<c011f1e4>] (__vfs_write) from [<c011f390>]
(vfs_write+0xb4/0x1a4)
[ 244.184093] [<c011f390>] (vfs_write) from [<c011f554>] (SyS_write+0x44/0x88)
[ 244.191326] [<c011f554>] (SyS_write) from [<c000a2c0>]
(ret_fast_syscall+0x0/0x1c)
[ 244.199057]
[ 244.199057] Showing all locks held in the system:
[ 244.205321] 2 locks held by khungtaskd/10:
[ 244.209569] #0: [ 244.211361] (
rcu_read_lock[ 244.214221] ){......}
, at: [ 244.217216] [<c00936ac>] watchdog+0xb4/0x61c
[ 244.221536] #1: [ 244.223308] (
tasklist_lock[ 244.226157] ){.+.+..}
, at: [ 244.229244] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
[ 244.234628] 4 locks held by ext4lazyinit/69:
[ 244.239047] #0: [ 244.240835] (
&type->s_umount_key[ 244.244214] #22
){++++++}[ 244.246796] , at:
[ 244.248987] [<c01ba260>] ext4_lazyinit_thread+0xd4/0x398
[ 244.254340] #1: [ 244.256116] (
sb_writers[ 244.258845] #3
){.+.+.+}[ 244.261355] , at:
[ 244.263417] [<c01ba278>] ext4_lazyinit_thread+0xec/0x398
[ 244.268876] #2: [ 244.270667] (
jbd2_handle[ 244.273350] ){++++..}
, at: [ 244.276230] [<c01f62b8>] start_this_handle+0xec/0x404
[ 244.281439] #3: [ 244.283228] (
&meta_group_info[i]->alloc_sem[ 244.287682] ){++++..}
, at: [ 244.290589] [<c01969f4>] ext4_init_inode_table+0xb8/0x3b0
[ 244.296045] 4 locks held by bash/386:
[ 244.299857] #0: [ 244.301644] (
sb_writers[ 244.304241] #4
){.+.+.+}[ 244.306738] , at:
[ 244.308925] [<c011f470>] vfs_write+0x194/0x1a4
[ 244.313408] #1: [ 244.315183] (
&of->mutex[ 244.317895] ){+.+.+.}
, at: [ 244.320792] [<c018ff38>] kernfs_fop_write+0xc0/0x1d0
[ 244.325791] #2: [ 244.327679] (
s_active[ 244.330126] #44
){.+.+.+}[ 244.332713] , at:
[ 244.334771] [<c018ff40>] kernfs_fop_write+0xc8/0x1d0
[ 244.339881] #3: [ 244.341668] (
pm_mutex[ 244.344087] ){+.+.+.}
, at: [ 244.346963] [<c005b520>] pm_suspend+0x98/0x784
[ 244.351579]
[ 244.353102] =============================================
[ 244.353102]
^ permalink raw reply
* [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Hanjun Guo @ 2016-10-23 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476812509-2760-2-git-send-email-agustinv@codeaurora.org>
On 2016/10/19 1:41, Agustin Vega-Frias wrote:
> This allows irqchip drivers to associate an ACPI DSDT device to
> an IRQ domain and provides support for using the ResourceSource
> in Extended IRQ Resources to find the domain and map the IRQs
> specified on that domain.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
[...]
> +/**
> + * acpi_irq_domain_register_irq() - Register the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + * @trigger: trigger type of the IRQ number to be mapped
> + * @polarity: polarity of the IRQ to be mapped
> + *
> + * Returns: a valid linux IRQ number on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EPROBE_DEFER if the IRQ domain has not been registered
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity)
> +{
> + struct irq_fwspec fwspec;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret;
> +
> + /* An empty acpi_resource_source means it is a GSI */
> + if (!source->string_length)
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + ret = acpi_irq_domain_ensure_probed(device);
> + if (ret)
> + goto out_put_device;
> +
> + fwspec.fwnode = &device->fwnode;
> + fwspec.param[0] = hwirq;
> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> + fwspec.param_count = 2;
> +
> + ret = irq_create_fwspec_mapping(&fwspec);
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
> +
> +/**
> + * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + *
> + * Returns: 0 on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq)
> +{
> + struct irq_domain *domain;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret = 0;
> +
> + if (!source->string_length) {
> + acpi_unregister_gsi(hwirq);
> + return 0;
> + }
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + domain = irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY);
> + if (!domain) {
> + ret = -EINVAL;
> + goto out_put_device;
> + }
> +
> + irq_dispose_mapping(irq_find_mapping(domain, hwirq));
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
I think Marc already raised this before, which irqdomain.c is similar to
gsi.c in drivers/acpi/, I prepared another approach [1] which avoid this,
I'm open for comments.
I think it's pretty important to finalize the directions we are going,
then avoid the duplicate work and speedup for upstream, Marc, Rafael,
Lorenzo, could you give us suggestions for this?
Thanks
Hanjun
[1]: https://patchwork.kernel.org/patch/9331771/
^ permalink raw reply
* [PATCH -next] ARM: mediatek: add terminate entry for of_device_id tables
From: Wei Yongjun @ 2016-10-23 11:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Make sure of_device_id tables are NULL terminated.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
arch/arm/mach-mediatek/platsmp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-mediatek/platsmp.c b/arch/arm/mach-mediatek/platsmp.c
index b821e34..e6cffc7 100644
--- a/arch/arm/mach-mediatek/platsmp.c
+++ b/arch/arm/mach-mediatek/platsmp.c
@@ -54,11 +54,13 @@ static const struct of_device_id mtk_tz_smp_boot_infos[] __initconst = {
{ .compatible = "mediatek,mt8135", .data = &mtk_mt8135_tz_boot },
{ .compatible = "mediatek,mt8127", .data = &mtk_mt8135_tz_boot },
{ .compatible = "mediatek,mt2701", .data = &mtk_mt8135_tz_boot },
+ { },
};
static const struct of_device_id mtk_smp_boot_infos[] __initconst = {
{ .compatible = "mediatek,mt6589", .data = &mtk_mt6589_boot },
{ .compatible = "mediatek,mt7623", .data = &mtk_mt7623_boot },
+ { },
};
static void __iomem *mtk_smp_base;
^ permalink raw reply related
* [PATCH 1/3] arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
From: Shawn Guo @ 2016-10-23 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <962ea92f-870b-e1d0-5bb7-1a6d66c35122@huawei.com>
On Sun, Oct 23, 2016 at 11:21:10AM +0800, Ding Tianhong wrote:
> This erratum describes a bug in logic outside the core, so MIDR can't be
> used to identify its presence, and reading an SoC-specific revision
> register from common arch timer code would be awkward. So, describe it
> in the device tree.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
> index ef5fbe9..26bc837 100644
> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
> @@ -31,6 +31,12 @@ to deliver its interrupts via SPIs.
> This also affects writes to the tval register, due to the implicit
> counter read.
>
> +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
> + QorIQ erratum 161201, which says that reading the counter is
QorIQ is a Freescale/NXP specific name, and shouldn't be there.
Shawn
> + unreliable unless the small range of value is returned by back-to-back reads.
> + This also affects writes to the tval register, due to the implicit
> + counter read.
> +
> ** Optional properties:
>
> - arm,cpu-registers-not-fw-configured : Firmware does not initialize
> --
> 1.9.0
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 01/10] ethernet: add sun8i-emac driver
From: Rami Rosen @ 2016-10-23 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-2-git-send-email-clabbe.montjoie@gmail.com>
Hi Corentin,
Trivial comment: rx_saf_fai and rx_daf_fail are not used. This implies that also
rx_saf_error and rx_daf_error should be removed:
> +static const char const estats_str[][ETH_GSTRING_LEN] = {
...
> + "rx_header_error",
> + "rx_overflow_error",
> + "rx_saf_error",
> + "rx_daf_error",
> + "rx_buf_error",
...
> +
> +struct sun8i_emac_stats {
> + u64 rx_payload_error;
...
> + u64 rx_overflow_error;
> + u64 rx_saf_fail;
> + u64 rx_daf_fail;
> + u64 tx_used_desc;
> + u64 napi_schedule;
> + u64 napi_underflow;
> +};
> +
Trivial: typo, should be: can transfer
> +/* The datasheet said that each descriptor can transfers up to 4096bytes
> + * But latter, a register documentation reduce that value to 2048
Regards,
Rami Rosen
^ permalink raw reply
* [PATCH] ARM: dts: imx: b650v3: Calibrate USB PHY to pass eye diagram test
From: Shawn Guo @ 2016-10-23 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473887689-10792-1-git-send-email-jaret.cantu@timesys.com>
On Wed, Sep 14, 2016 at 05:14:49PM -0400, Jaret Cantu wrote:
> Calibrate the USB PHY TX settings to pass the eye diagram signal
> integrity test. The settings are taken from the i.MX6 reference
> manual's recommended configuration for USB certification (66.2.6).
>
> Signed-off-by: Jaret Cantu <jaret.cantu@timesys.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: imx6qdl cleanups
From: Shawn Guo @ 2016-10-23 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437970-15800-1-git-send-email-jteki@openedev.com>
On Fri, Oct 14, 2016 at 03:09:27PM +0530, Jagan Teki wrote:
> Patchset for imx6qdl devicetree files cleanups.
>
> Jagan Teki (3):
> arm: dts: imx6qdl: Fix "WARNING: please, no space before tabs"
> arm: dts: imx6qdl: Fix "ERROR: code indent should use tabs where
> possible"
> arm: dts: imx6qdl-wandboard-revb: Fix "ERROR: trailing whitespace"
Applied, thanks.
^ permalink raw reply
* [PATCH v2 0/4] ARM: imx31: clock initialization fixes
From: Shawn Guo @ 2016-10-23 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-1-git-send-email-vz@mleia.com>
On Mon, Sep 26, 2016 at 03:03:39AM +0300, Vladimir Zapolskiy wrote:
> The change is tested on qemu kzm target and mx31lite board, while both
> targets don't have DTS in upstream, I had to write simple DTS files for
> them, because the proposed change is for i.MX31 targets with OF support.
>
> i.MX31/OF/clock initialization seems to be broken currently, if
> the series is not applied I can not get a working clock source during
> early boot stage on a board with DTB supplied.
>
> Changes from v1 to v2, thanks to Uwe and Stephen for review:
> * added one more new fix in imx31.dtsi which moves CCM device node
> to AIPS2 bus,
> * included to the series a fix of CCM interrupts in imx31.dtsi,
> the change was sent as a separate patch, the change is included
> to avoid a patch application dependency,
> * as suggested by Uwe reworded one of the commits removing "stack
> corruption" mentioning, the overwritten value is passed in a register,
> * as suggested by Uwe squashed clk-imx31.c and imx31-dt.c changes
> to avoid a runtime problem if only one of two patches are applied
>
> Vladimir Zapolskiy (4):
> ARM: dts: imx31: fix clock control module interrupts description
> ARM: dts: imx31: move CCM device node to AIPS2 bus devices
> clk: imx31: fix rewritten input argument of mx31_clocks_init()
> ARM: clk: imx31: properly init clocks for machines with DT
>
> .../devicetree/bindings/clock/imx31-clock.txt | 2 +-
> arch/arm/boot/dts/imx31.dtsi | 14 +++---
> arch/arm/mach-imx/common.h | 1 -
> arch/arm/mach-imx/imx31-dt.c | 6 ---
> drivers/clk/imx/clk-imx31.c | 52 +++++++++++-----------
Hi Stephen,
Can I have you ACK on the clk file, so that we can merge the series from
arm-soc tree? Thanks.
Shawn
^ permalink raw reply
* [PATCH 1/1 v8] ARM: imx: Added perf functionality to mmdc driver
From: Shawn Guo @ 2016-10-23 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474307849-7341-1-git-send-email-Frank.Li@nxp.com>
On Mon, Sep 19, 2016 at 12:57:29PM -0500, Frank Li wrote:
> From: Zhengyu Shen <zhengyu.shen@nxp.com>
>
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
> MMDC provides registers for performance counters which read via this
> driver to help debug memory throughput and similar issues.
>
> $ perf stat -a -e mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/ dd if=/dev/zero of=/dev/null bs=1M count=5000
> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
>
> 898021787 mmdc/busy-cycles/
> 14819600 mmdc/read-accesses/
> 471.30 MB mmdc/read-bytes/
> 2815419216 mmdc/total-cycles/
> 13367354 mmdc/write-accesses/
> 427.76 MB mmdc/write-bytes/
>
> 5.334757334 seconds time elapsed
>
> Signed-off-by: Zhengyu Shen <zhengyu.shen@nxp.com>
> Signed-off-by: Frank Li <frank.li@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 1/4] ARM: dts: mxs: Add new M28EVK manufacturer compat
From: Shawn Guo @ 2016-10-23 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-1-marex@denx.de>
On Mon, Sep 19, 2016 at 11:40:41PM +0200, Marek Vasut wrote:
> The board is now manufactured by Aries Embedded GmbH, update compat string.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> ---
> arch/arm/boot/dts/imx28-m28.dtsi | 4 ++--
> arch/arm/boot/dts/imx28-m28evk.dts | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx28-m28.dtsi b/arch/arm/boot/dts/imx28-m28.dtsi
> index 214bb15..a69856e 100644
> --- a/arch/arm/boot/dts/imx28-m28.dtsi
> +++ b/arch/arm/boot/dts/imx28-m28.dtsi
> @@ -12,8 +12,8 @@
> #include "imx28.dtsi"
>
> / {
> - model = "DENX M28";
> - compatible = "denx,m28", "fsl,imx28";
> + model = "Aries/DENX M28";
> + compatible = "aries,m28", "denx,m28", "fsl,imx28";
Do we have an entry for Aries Embedded GmbH in vendor-prefixes.txt?
Shawn
>
> memory {
> reg = <0x40000000 0x08000000>;
> diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
> index 8d04e57..dbfb8aa 100644
> --- a/arch/arm/boot/dts/imx28-m28evk.dts
> +++ b/arch/arm/boot/dts/imx28-m28evk.dts
> @@ -13,8 +13,8 @@
> #include "imx28-m28.dtsi"
>
> / {
> - model = "DENX M28EVK";
> - compatible = "denx,m28evk", "fsl,imx28";
> + model = "Aries/DENX M28EVK";
> + compatible = "aries,m28evk", "denx,m28evk", "fsl,imx28";
>
> apb at 80000000 {
> apbh at 80000000 {
> --
> 2.9.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] ARM: dts: mxs: Add new M28EVK manufacturer compat
From: Marek Vasut @ 2016-10-23 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023130143.GT30578@tiger>
On 10/23/2016 03:01 PM, Shawn Guo wrote:
> On Mon, Sep 19, 2016 at 11:40:41PM +0200, Marek Vasut wrote:
>> The board is now manufactured by Aries Embedded GmbH, update compat string.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> ---
>> arch/arm/boot/dts/imx28-m28.dtsi | 4 ++--
>> arch/arm/boot/dts/imx28-m28evk.dts | 4 ++--
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx28-m28.dtsi b/arch/arm/boot/dts/imx28-m28.dtsi
>> index 214bb15..a69856e 100644
>> --- a/arch/arm/boot/dts/imx28-m28.dtsi
>> +++ b/arch/arm/boot/dts/imx28-m28.dtsi
>> @@ -12,8 +12,8 @@
>> #include "imx28.dtsi"
>>
>> / {
>> - model = "DENX M28";
>> - compatible = "denx,m28", "fsl,imx28";
>> + model = "Aries/DENX M28";
>> + compatible = "aries,m28", "denx,m28", "fsl,imx28";
>
> Do we have an entry for Aries Embedded GmbH in vendor-prefixes.txt?
The patch was submitted, not yet applied though:
http://www.spinics.net/lists/arm-kernel/msg533000.html
--
Best regards,
Marek Vasut
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Russell King - ARM Linux @ 2016-10-23 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <315017958.66634.5d4fc19c-31cd-4900-8613-af4cadec5da4.open-xchange@email.1und1.de>
On Sun, Oct 23, 2016 at 11:19:26AM +0200, Stefan Wahren wrote:
> Hi,
>
> i'm faced with the issue that on i.MX28 the console is unable to wake up from
> freeze ( suspend to idle). I tested it with Linux 4.9-rc1, 4.8 and 3.18 (
> cmdline has
> no_console_suspend=1 ) and also with a i.MX23 with the same result. The suspend
> seems to work, but there is no reaction to the console after the freeze except
> an hung task warning after some time:
I bet if you remove "no_console_suspend" (it's not =1) then it'll work.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Remove I2C3
From: Shawn Guo @ 2016-10-23 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475371719-28736-1-git-send-email-andrew.smirnov@gmail.com>
On Sat, Oct 01, 2016 at 06:28:39PM -0700, Andrey Smirnov wrote:
> I2C3 bus was only brought out in revision A1 of the board and revision
> B1 only brings out 3 I2C busses (I2C0, I2C1 and I2C2).
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: vfxxx: Add node corresponding to OCOTP
From: Shawn Guo @ 2016-10-23 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475371822-28879-1-git-send-email-andrew.smirnov@gmail.com>
On Sat, Oct 01, 2016 at 06:30:22PM -0700, Andrey Smirnov wrote:
> Add node corresponding to OCOTP IP block.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Shawn Guo @ 2016-10-23 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161002164435.5812-1-marex@denx.de>
On Sun, Oct 02, 2016 at 06:44:35PM +0200, Marek Vasut wrote:
> The LCDIF interrupt should be triggered by the rising edge of the
> IRQ line because we only want the interrupt to trigger once per each
> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
> by software, so the previous behavior before this patch, where the
> interrupt was triggered by level-high status of the IRQ line, caused
> the interrupt to fire again immediatelly after it was handled, which
> caused the system to lock up due to the high rate of interrupts.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
Applied, thanks.
^ permalink raw reply
* [PATCH 01/14] dma: sun6i-dma: Add burst case of 4
From: Jean-Francois Moine @ 2016-10-23 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004165553.GS5228@lukather>
On Tue, 4 Oct 2016 18:55:54 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Tue, Oct 04, 2016 at 12:40:11PM +0200, Jean-Francois Moine wrote:
> > On Tue, 4 Oct 2016 11:46:14 +0200
> > Myl?ne Josserand <mylene.josserand@free-electrons.com> wrote:
> >
> > > Add the case of a burst of 4 which is handled by the SoC.
> > >
> > > Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
> > > ---
> > > drivers/dma/sun6i-dma.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > > index 8346199..0485204 100644
> > > --- a/drivers/dma/sun6i-dma.c
> > > +++ b/drivers/dma/sun6i-dma.c
> > > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > > switch (maxburst) {
> > > case 1:
> > > return 0;
> > > + case 4:
> > > + return 1;
> > > case 8:
> > > return 2;
> > > default:
> > > --
> > > 2.9.3
> >
> > This patch has already been rejected by Maxime in the threads
> > http://www.spinics.net/lists/dmaengine/msg08610.html
> > and
> > http://www.spinics.net/lists/dmaengine/msg08719.html
> >
> > I hope you will find the way he wants for this maxburst to be added.
>
> I was talking about something along these lines (not tested):
I wonder why you don't submit this yourself.
> -------8<---------
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 83461994e418..573ac4608293 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> switch (maxburst) {
> case 1:
> return 0;
> + case 4:
> + return 1;
> case 8:
> return 2;
> default:
> @@ -1110,11 +1112,19 @@ static int sun6i_dma_probe(struct platform_device *pdev)
> sdc->slave.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> + sdc->slave.dst_bursts = BIT(1) | BIT(8);
> + sdc->slave.src_bursts = BIT(1) | BIT(8);
> sdc->slave.directions = BIT(DMA_DEV_TO_MEM) |
> BIT(DMA_MEM_TO_DEV);
> sdc->slave.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> sdc->slave.dev = &pdev->dev;
>
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun8i-h3-dma")) {
> + sdc->slave.dst_bursts |= BIT(4);
> + sdc->slave.src_bursts |= BIT(4);
> + }
> +
> sdc->pchans = devm_kcalloc(&pdev->dev, sdc->cfg->nr_max_channels,
> sizeof(struct sun6i_pchan), GFP_KERNEL);
> if (!sdc->pchans)
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index cc535a478bae..f7bbec24bb58 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -673,6 +673,8 @@ struct dma_filter {
> * each type of direction, the dma controller should fill (1 <<
> * <TYPE>) and same should be checked by controller as well
> * @max_burst: max burst capability per-transfer
> + * @dst_bursts: bitfield of the available burst sizes for the destination
> + * @src_bursts: bitfield of the available burst sizes for the source
You did not define dst_bursts nor src_bursts.
> * @residue_granularity: granularity of the transfer residue reported
> * by tx_status
> * @device_alloc_chan_resources: allocate resources and return the
> @@ -800,6 +802,14 @@ struct dma_device {
> static inline int dmaengine_slave_config(struct dma_chan *chan,
> struct dma_slave_config *config)
> {
> + if (config->src_maxburst && config->device->src_bursts &&
> + !(BIT(config->src_maxburst) & config->device->src_bursts))
The maxburst may be as big as 4Kibytes, then, I am not sure that this
code will work!
> + return -EINVAL;
> +
> + if (config->dst_maxburst && config->device->dst_bursts &&
> + !(BIT(config->dst_maxburst) & config->device->dst_bursts))
> + return -EINVAL;
> +
> if (chan->device->device_config)
> return chan->device->device_config(chan, config);
> -------8<------------
Yes, I know that the burst size is always a power of 2.
The best way to check it would be to change the {src,dts}_maxburst to a
bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes. But this
asks for a lot of changes...
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 0/6] clk: oxnas: Rework driver to add support for OX820
From: Michael Turquette @ 2016-10-23 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147617274057.17481.2362814012745242458@resonance>
Quoting Michael Turquette (2016-10-11 00:59:00)
> Quoting Neil Armstrong (2016-10-05 17:07:46)
> > In order to to support the Oxford Semiconductor OX820 Soc clock gates,
> > rework the original driver with a structure inspired from the Qcom or Meson
> > drivers and using the new devm_clk_hw_register() call.
> >
> > The first patches add dt-bindings include file to clarify the clock indices.
> >
> > In future work, OX820 PLLs should also be handled by this driver.
>
> Series looks good to me. Will apply after -rc1 drops.
Applied.
Regards,
Mike
>
> Regards,
> Mike
>
> >
> > Neil Armstrong (6):
> > clk: oxnas: Add dt-bindings include file for OX810SE
> > clk: oxnas: Add dt-bindings include file for OX820
> > clk: oxnas: Rename to clk_oxnas_gate
> > clk: oxnas: Refactor to make use of devm_clk_hw_register()
> > clk: oxnas: Add OX820 Gate clocks
> > dt-bindings: clk: oxnas,stdclk: Add OX820 bindings
> >
> > .../devicetree/bindings/clock/oxnas,stdclk.txt | 19 +-
> > drivers/clk/clk-oxnas.c | 232 ++++++++++++++-------
> > include/dt-bindings/clock/oxsemi,ox810se.h | 30 +++
> > include/dt-bindings/clock/oxsemi,ox820.h | 40 ++++
> > 4 files changed, 231 insertions(+), 90 deletions(-)
> > create mode 100644 include/dt-bindings/clock/oxsemi,ox810se.h
> > create mode 100644 include/dt-bindings/clock/oxsemi,ox820.h
> >
> > --
> > 2.7.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RFC 0/10] tda998x initial cleanups from bridge conversion
From: Russell King - ARM Linux @ 2016-10-23 19:10 UTC (permalink / raw)
To: linux-arm-kernel
As part of the discussion about converting tda998x to a bridge, here's
some preparatory work for that, which includes a bunch of fixes. I'm
sending this out _early_ as I'm not going to be working on any kernel
stuff next week (it's likely I won't even be reading email.) So it may
be a little rough around the edges.
Essentially, this is a series of cleanups, complexity removal, and
avoiding races with the newly introduced audio support. Even without
the bridge conversion, I think all these are still worthwhile to have.
This series of changes can also be found in my drm-tda998x-devel branch
as an unstable series of commits (iow, I'm going to rebase/rework these
at some point, so the commit IDs are not stable, so do not merge this.)
git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
drivers/gpu/drm/i2c/tda998x_drv.c | 782 +++++++++++++++++++-------------------
1 file changed, 394 insertions(+), 388 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH RFC 01/10] drm/i2c: tda998x: avoid race in tda998x_encoder_mode_set()
From: Russell King @ 2016-10-23 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023191002.GJ1041@n2100.armlinux.org.uk>
As priv->audio_params can now be changed at run time, we need to be more
careful about how we deal with a mode set. We must take the audio lock
while checking if there's a valid audio configuration.
However, it's slightly worse than that - during mode set, we mute the
audio, and it must not be unmuted until we have finished the mode set.
It is possible that the audio side may start while a mode set is in
progress, so take the audio_mutex lock around the whole mode setting
procedure.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 9798d400d817..d72bc30a3bce 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1074,13 +1074,12 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
tda998x_write_avi(priv, adjusted_mode);
- if (priv->audio_params.format != AFMT_UNUSED) {
- mutex_lock(&priv->audio_mutex);
+ mutex_lock(&priv->audio_mutex);
+ if (priv->audio_params.format != AFMT_UNUSED)
tda998x_configure_audio(priv,
&priv->audio_params,
adjusted_mode->clock);
- mutex_unlock(&priv->audio_mutex);
- }
+ mutex_unlock(&priv->audio_mutex);
}
}
--
2.1.0
^ permalink raw reply related
* [PATCH RFC 02/10] drm/i2c: tda998x: avoid configuring audio for DVI mode
From: Russell King @ 2016-10-23 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023191002.GJ1041@n2100.armlinux.org.uk>
We must not configure the audio path when the sink is a DVI device, as
DVI has no capability to receive HDMI audio. HDMI audio is a HDMI only
feature, requiring HDMI infoframes.
There's a question concerning how to handle a DVI connected device when
the audio device is opened - we save the audio configuration, so that if
a HDMI device is hotplugged, audio will then work. This seems a
reasonable expectation.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index d72bc30a3bce..495ee3fed661 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -44,6 +44,7 @@ struct tda998x_priv {
u8 current_page;
int dpms;
bool is_hdmi_sink;
+ bool is_hdmi_config;
u8 vip_cntrl_0;
u8 vip_cntrl_1;
u8 vip_cntrl_2;
@@ -971,6 +972,8 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
div = 3;
}
+ mutex_lock(&priv->audio_mutex);
+
/* mute the audio FIFO: */
reg_set(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_FIFO);
@@ -1074,13 +1077,14 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
tda998x_write_avi(priv, adjusted_mode);
- mutex_lock(&priv->audio_mutex);
if (priv->audio_params.format != AFMT_UNUSED)
tda998x_configure_audio(priv,
&priv->audio_params,
adjusted_mode->clock);
- mutex_unlock(&priv->audio_mutex);
}
+
+ priv->is_hdmi_config = priv->is_hdmi_sink;
+ mutex_unlock(&priv->audio_mutex);
}
static enum drm_connector_status
@@ -1264,9 +1268,12 @@ static int tda998x_audio_hw_params(struct device *dev, void *data,
}
mutex_lock(&priv->audio_mutex);
- ret = tda998x_configure_audio(priv,
- &audio,
- priv->encoder.crtc->hwmode.clock);
+ /* We must not program the TDA998x for audio if the sink is DVI. */
+ if (priv->is_hdmi_config)
+ ret = tda998x_configure_audio(priv, &audio,
+ priv->encoder.crtc->hwmode.clock);
+ else
+ ret = 0;
if (ret == 0)
priv->audio_params = audio;
--
2.1.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox