* Re: [PATCHv2 2/3] ARM: drm: Intel FPGA VIP Frame Buffer II drm driver
From: Eric Anholt @ 2017-05-03 20:34 UTC (permalink / raw)
To: daniel.vetter, dinguyen, robh+dt
Cc: hean.loong.ong, devicetree, tien.hock.loh, dri-devel, Ong
In-Reply-To: <1493086006-4392-3-git-send-email-hean.loong.ong@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 9774 bytes --]
hean.loong.ong@intel.com writes:
> From: "Ong, Hean Loong" <hean.loong.ong@intel.com>
>
> Driver for Intel FPGA Video and Image Processing
> Suite Frame Buffer II. The driver only supports the Intel
> Arria10 devkit and its variants. This driver can be either
> loaded staticlly or in modules. The OF device tree binding
> is located at:
> Documentation/devicetree/bindings/display/altr,vip-fb2.txt
>
> Signed-off-by: Ong, Hean Loong <hean.loong.ong@intel.com>
I'm not sure if this driver is going to make sense as-is, if it doesn't
actually do display of planes from system memory. But in case I was
wrong, here's my review:
> diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c b/drivers/gpu/drm/ivip/intel_vip_conn.c
> new file mode 100644
> index 0000000..499d3b4
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
> @@ -0,0 +1,96 @@
> +/*
> + * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * Authors:
> + * Ong, Hean-Loong <hean.loong.ong@intel.com>
> + *
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_encoder_slave.h>
> +#include <drm/drm_plane_helper.h>
> +
> +static enum drm_connector_status
> +intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_connected;
> +}
> +
> +static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_unregister(connector);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
> + .dpms = drm_helper_connector_dpms,
> + .reset = drm_atomic_helper_connector_reset,
> + .detect = intelvipfb_drm_connector_detect,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = intelvipfb_drm_connector_destroy,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static int intelvipfb_drm_connector_get_modes(struct drm_connector *connector)
> +{
> + struct drm_device *drm = connector->dev;
> + int count;
> +
> + count = drm_add_modes_noedid(connector, drm->mode_config.max_width,
> + drm->mode_config.max_height);
> + drm_set_preferred_mode(connector, drm->mode_config.max_width,
> + drm->mode_config.max_height);
> + return count;
> +}
You're adding a bunch of modes here, but I don't see anywhere in the
driver that you change the resolution being scanned out.
If you can't change resolution, then I'd probably use drm_gtf_mode() or
something to generate just the one mode (do you have a vrefresh for
it?). Also, in the simple display pipe's atomic_check, make sure that
the mode chosen is the width/height you can support.
> +
> +static const struct drm_connector_helper_funcs
> +intelvipfb_drm_connector_helper_funcs = {
> + .get_modes = intelvipfb_drm_connector_get_modes,
> +};
> +
> +struct drm_connector *
> +intelvipfb_conn_setup(struct drm_device *drm)
> +{
> + struct drm_connector *conn;
> + int ret;
> +
> + conn = devm_kzalloc(drm->dev, sizeof(*conn), GFP_KERNEL);
> + if (IS_ERR(conn))
> + return NULL;
> +
> + ret = drm_connector_init(drm, conn, &intelvipfb_drm_connector_funcs,
> + DRM_MODE_CONNECTOR_DisplayPort);
Are you actually outputting DisplayPort
(https://en.wikipedia.org/wiki/DisplayPort)?
You probably want something else from the DRM_MODE_CONNECTOR list, or
maybe just DRM_MODE_CONNECTOR_Unknown.
> + if (ret < 0) {
> + dev_err(drm->dev, "failed to initialize drm connector\n");
> + ret = -ENOMEM;
> + goto error_connector_cleanup;
> + }
> +
> + drm_connector_helper_add(conn, &intelvipfb_drm_connector_helper_funcs);
> +
> + return conn;
> +
> +error_connector_cleanup:
> + drm_connector_cleanup(conn);
> +
> + return NULL;
> +}
> diff --git a/drivers/gpu/drm/ivip/intel_vip_core.c b/drivers/gpu/drm/ivip/intel_vip_core.c
> new file mode 100644
> index 0000000..4e83343
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_core.c
> @@ -0,0 +1,171 @@
> +/*
> + * intel_vip_core.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * Authors:
> + * Ong, Hean-Loong <hean.loong.ong@intel.com>
> + *
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_fb_helper.h>
> +#include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_plane_helper.h>
> +#include <drm/drm_simple_kms_helper.h>
> +
> +#include "intel_vip_drv.h"
> +
> +static const u32 fbpriv_formats[] = {
> + DRM_FORMAT_XRGB8888,
> + DRM_FORMAT_RGB565
> +};
You're registering that you support this set of formats, but I don't see
anything programming the hardware differently based on the format of the
plane.
> +static void intelvipfb_start_hw(void __iomem *base, resource_size_t addr)
> +{
> + /*
> + * The frameinfo variable has to correspond to the size of the VIP Suite
> + * Frame Reader register 7 which will determine the maximum size used
> + * in this frameinfo
> + */
> +
> + u32 frameinfo;
> +
> + frameinfo =
> + readl(base + INTELVIPFB_FRAME_READER) & 0x00ffffff;
> + writel(frameinfo, base + INTELVIPFB_FRAME_INFO);
> + writel(addr, base + INTELVIPFB_FRAME_START);
> + /* Finally set the control register to 1 to start streaming */
> + writel(1, base + INTELVIPFB_CONTROL);
> +}
The addr you're passing in here is from dev->mode_config.fb_base, which
is this weird sideband value from drm_fbdev_cma. It's the wrong value
to use if anything else uses the KMS interfaces to change the plane --
you should be using
drm_fb_cma_get_gem_addr(drm_simple_display_pipe->plane->state, 0)
instead.
> +
> +static void intelvipfb_disable_hw(void __iomem *base)
> +{
> + /* set the control register to 0 to stop streaming */
> + writel(0, base + INTELVIPFB_CONTROL);
> +}
These two functions should be be called from fbpriv_funcs.enable() and
.disable(), not device load/unload.
> +static const struct drm_mode_config_funcs intelvipfb_mode_config_funcs = {
> + .fb_create = drm_fb_cma_create,
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static struct drm_mode_config_helper_funcs intelvipfb_mode_config_helpers = {
> + .atomic_commit_tail = drm_atomic_helper_commit_tail,
> +};
> +
> +static void intelvipfb_setup_mode_config(struct drm_device *drm)
> +{
> + drm_mode_config_init(drm);
> + drm->mode_config.funcs = &intelvipfb_mode_config_funcs;
> + drm->mode_config.helper_private = &intelvipfb_mode_config_helpers;
> +}
> +
> +static int intelvipfb_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
> + struct drm_plane_state *plane_state)
> +{
> + return drm_fb_cma_prepare_fb(&pipe->plane, plane_state);
> +}
> +
> +static struct drm_simple_display_pipe_funcs fbpriv_funcs = {
> + .prepare_fb = intelvipfb_pipe_prepare_fb,
> +};
> +
> +int intelvipfb_probe(struct device *dev, void __iomem *base)
> +{
> + int retval;
> + struct drm_device *drm;
> + struct intelvipfb_priv *fbpriv = dev_get_drvdata(dev);
> + struct drm_connector *connector;
> +
> + dev_set_drvdata(dev, fbpriv);
> +
> + drm = fbpriv->drm;
> +
> + intelvipfb_setup_mode_config(drm);
> +
> + connector = intelvipfb_conn_setup(drm);
> + if (!connector) {
> + dev_err(drm->dev, "Connector setup failed\n");
> + goto err_mode_config;
> + }
> +
> + retval = drm_simple_display_pipe_init(drm, &fbpriv->pipe,
> + &fbpriv_funcs,
> + fbpriv_formats,
> + ARRAY_SIZE(fbpriv_formats),
> + connector);
> + if (retval < 0) {
> + dev_err(drm->dev, "Cannot setup simple display pipe\n");
> + goto err_mode_config;
> + }
> +
> + fbpriv->fbcma = drm_fbdev_cma_init(drm, PREF_BPP,
> + drm->mode_config.num_connector);
> + if (!fbpriv->fbcma) {
> + fbpriv->fbcma = NULL;
> + dev_err(drm->dev, "Failed to init FB CMA area\n");
> + goto err_mode_config;
> + }
On failure, drm_fbdev_cma_init() returns an ERR_PTR, not NULL.
Also, you're passing this PREF_BPP value here, ignoring
the altr,bits-per-symbol property. That seems wrong.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes
From: Maxime Ripard @ 2017-05-03 20:34 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170503031658.29299-4-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
Hi,
On Wed, May 03, 2017 at 11:16:53AM +0800, Chen-Yu Tsai wrote:
> The MMC clocks on newer SoCs, such as the A83T and H3, support the
> "new timing mode". Under this mode, the output of the clock is divided
> by 2, and the clock delays no longer apply.
>
> Due to how the clock tree is modeled and setup, we need to model
> this function in two places, the master mmc clock and the two
> child phase clocks. In the mmc clock, we can easily model the
> mode bit as an extra variable post-divider. In the phase clocks,
> we check the bit and return -ENOTSUPP if the bit is set, signaling
> that the phase clocks are not to be used.
>
> This patch introduces a class of phase clocks that checks the
> timing mode bit.
We've been over this quite some times already...
How do you retrieve the mode used in the clock so that you can also
switch the MMC driver in the new mode?
And do you prevent that from happening on the DT we already have that
use the old clock drivers that do not support this new timing at all?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCHv2 0/3] Intel FPGA VIP Frame Buffer II DRM Driver
From: Eric Anholt @ 2017-05-03 20:28 UTC (permalink / raw)
To: daniel.vetter-ral2JQCrhuEAvxtiuMwx3w,
dinguyen-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
tien.hock.loh-ral2JQCrhuEAvxtiuMwx3w,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <1493086006-4392-1-git-send-email-hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org writes:
> From: Ong Hean Loong <hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> Hi,
>
> The new Intel Arria10 SOC FPGA devkit has a Display Port IP component
> which requires a new driver. This is a virtual driver in which the
> FGPA hardware would enable the Display Port based on the information
> and data provided from the DRM frame buffer from the OS. Basically all
> all information with reagrds to resolution and bits per pixel are
> pre-configured on the FPGA design and these information are fed to
> the driver via the device tree information as part of the hardware
> information.
I started reviewing the code, but I want to make sure I understand
what's going on:
This IP core isn't displaying contents from system memory on some sort
of actual physical display, right? It's a core that takes some input
video stream (not described in the DT or in this driver) and stores it
to memory?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/1] of: Move OF property and graph API from base.c to property.c
From: Rob Herring @ 2017-05-03 20:19 UTC (permalink / raw)
To: Sakari Ailus
Cc: devicetree@vger.kernel.org, Frank Rowand,
linux-acpi@vger.kernel.org, Sudeep Holla, Lorenzo Pieralisi,
mika.westerberg@linux.intel.com, Rafael J. Wysocki, Mark Rutland,
Mark Brown, Al Stone
In-Reply-To: <1493806898-5409-1-git-send-email-sakari.ailus@linux.intel.com>
On Wed, May 3, 2017 at 5:21 AM, Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
> base.c contains both core OF functions and increasingly other
> functionality such as accessing properties and graphs, including
> convenience functions. In the near future this would also include OF
> specific implementation of the fwnode property and graph APIs.
>
> Create driver/of/property.c to contain procedures for accessing and
> interpreting device tree properties. The procedures are moved from
> drivers/of/base.c, with no changes other than copying only the includes
> required by the moved procedures.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
> Hi Rob and Frank,
>
> This is a pre-dependency for further fwnode property cleanup. The patch
> appears to be slightly more conflict-prone than the rest of the patchset:
>
> <URL:http://www.spinics.net/lists/linux-acpi/msg72647.html>
>
> Would it be possible to merge it separately from the rest?
Yes, but not now in the middle of the merge window. Maybe towards the
end of the merge window for 4.12. Or it's not going to be until 4.13.
Rob
^ permalink raw reply
* Re: [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges
From: Rob Herring @ 2017-05-03 20:06 UTC (permalink / raw)
To: Oza Pawandeep
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Oza Pawandeep,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux IOMMU,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1493786795-28153-3-git-send-email-oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, May 2, 2017 at 11:46 PM, Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure is specifically written to take care of memory
> mapped devices. but no implementation exists for pci to take
> care of pcie based memory ranges.
>
> for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
> world dma-ranges.
> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
>
> this patch fixes this patch fixes the bug in of_dma_get_range,
> which with as is, parses the PCI memory ranges and return wrong
> size as 0.
>
> in order to get largest possible dma_mask. this patch also
> retuns the largest possible size based on dma-ranges,
>
> for e.g.
> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
> we should get dev->coherent_dma_mask=0x7fffffffff.
>
> based on which iova allocation space will honour PCI host
> bridge limitations.
>
> Bug: SOC-5216
> Change-Id: I4c534bdd17e70c6b27327d39d1656e8ed0cf56d6
> Signed-off-by: Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-on: http://gerrit-ccxsw.broadcom.net/40762
> Reviewed-by: vpx_checkpatch status <vpx_checkpatch-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: CCXSW <ccxswbuild-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Tested-by: vpx_autobuild status <vpx_autobuild-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Tested-by: vpx_smoketest status <vpx_smoketest-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..f7734fc 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -6,6 +6,7 @@
> #include <linux/ioport.h>
> #include <linux/module.h>
> #include <linux/of_address.h>
> +#include <linux/of_pci.h>
> #include <linux/pci.h>
> #include <linux/pci_regs.h>
> #include <linux/sizes.h>
> @@ -830,6 +831,54 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
> int ret = 0;
> u64 dmaaddr;
>
> +#ifdef CONFIG_PCI
> + struct resource_entry *window;
> + LIST_HEAD(res);
> +
> + if (!node)
> + return -EINVAL;
> +
> + if (of_bus_pci_match(np)) {
You are not following what I'm saying. Let me spell it out:
- Add a get_dma_ranges() function to of_bus struct. Or maybe should
cover ranges too (e.g. get_ranges). I'm not sure.
- Convert existing contents of this function to
of_bus_default_dma_get_ranges and add that to the default of_bus
struct.
- Make of_dma_get_range call of_bus_match() and then bus->get_dma_ranges.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
From: Rob Herring @ 2017-05-03 19:55 UTC (permalink / raw)
To: Oza Pawandeep
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Oza Pawandeep,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux IOMMU,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1493786795-28153-1-git-send-email-oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, May 2, 2017 at 11:46 PM, Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure is specifically written to take care of memory
> mapped devices. but no implementation exists for pci to take
> care of pcie based memory ranges.
>
> for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
> world dma-ranges.
> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
>
> this patch serves following:
>
> 1) exposes interface to the pci host driver for their
> inbound memory ranges
>
> 2) provide an interface to callers such as of_dma_get_ranges.
> so then the returned size get best possible (largest) dma_mask.
> because PCI RC drivers do not call APIs such as
> dma_set_coherent_mask() and hence rather it shows its addressing
> capabilities based on dma-ranges.
> for e.g.
> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
> we should get dev->coherent_dma_mask=0x7fffffffff.
>
> 3) this patch handles multiple inbound windows and dma-ranges.
> it is left to the caller, how it wants to use them.
> the new function returns the resources in a standard and unform way
>
> 4) this way the callers of for e.g. of_dma_get_ranges
> does not need to change.
>
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.
>
> Bug: SOC-5216
> Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e
> Signed-off-by: Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428
> Reviewed-by: vpx_checkpatch status <vpx_checkpatch-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: CCXSW <ccxswbuild-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Tested-by: vpx_autobuild status <vpx_autobuild-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Tested-by: vpx_smoketest status <vpx_smoketest-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Tested-by: CCXSW <ccxswbuild-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
All these non-person, probably internal Broadcom Tested-by and
Reviewed-by's should be removed too.
> Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
Rob
^ permalink raw reply
* [PATCH] of/unittest: Missing unlocks on error
From: Dan Carpenter @ 2017-05-03 19:49 UTC (permalink / raw)
To: Rob Herring, Frank Rowand; +Cc: Frank Rowand, devicetree, kernel-janitors
Static checkers complain that we should unlock before returning. Which
is true.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 12597ff8cfb0..425338d6286d 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -2210,14 +2210,14 @@ static __init void of_unittest_overlay_high_level(void)
unittest(0,
"duplicate property '%s' in overlay_base node __symbols__",
prop->name);
- return;
+ goto err_unlock;
}
ret = __of_add_property_sysfs(of_symbols, prop);
if (ret) {
unittest(0,
"unable to add property '%s' in overlay_base node __symbols__ to sysfs",
prop->name);
- return;
+ goto err_unlock;
}
}
}
@@ -2232,6 +2232,10 @@ static __init void of_unittest_overlay_high_level(void)
unittest(overlay_data_add(2),
"Adding overlay 'overlay_bad_phandle' failed\n");
+ return;
+
+err_unlock:
+ mutex_unlock(&of_mutex);
}
#else
^ permalink raw reply related
* Re: [PATCH v2 1/2] [media] dt-bindings: Add bindings for video-multiplexer device
From: Sakari Ailus @ 2017-05-03 19:30 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Steve Longerbeam, Peter Rosin,
Pavel Machek, Rob Herring, Mark Rutland, Vladimir Zapolskiy,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Sascha Hauer, Steve Longerbeam
In-Reply-To: <20170502150913.2168-1-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Thanks, Philipp!
On Tue, May 02, 2017 at 05:09:12PM +0200, Philipp Zabel wrote:
> Add bindings documentation for the video multiplexer device.
>
> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> Acked-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
> ---
> No changes since v1 [1].
>
> This was previously sent as part of Steve's i.MX media series [2].
>
> [1] https://patchwork.kernel.org/patch/9704789/
> [2] https://patchwork.kernel.org/patch/9647951/
> ---
Acked-by: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
--
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] [media] platform: add video-multiplexer subdevice driver
From: Sakari Ailus @ 2017-05-03 19:28 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-media, devicetree, Steve Longerbeam, Peter Rosin,
Pavel Machek, Rob Herring, Mark Rutland, Vladimir Zapolskiy,
kernel, Sascha Hauer, Steve Longerbeam
In-Reply-To: <20170502150913.2168-2-p.zabel@pengutronix.de>
Hi Philipp,
Thanks for continuing working on this!
I have some minor comments below...
On Tue, May 02, 2017 at 05:09:13PM +0200, Philipp Zabel wrote:
> This driver can handle SoC internal and external video bus multiplexers,
> controlled by mux controllers provided by the mux controller framework,
> such as MMIO register bitfields or GPIOs. The subdevice passes through
> the mbus configuration of the active input to the output side.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> Changes since v1 [1]:
> - Protect vmux->active with a mutex in link_setup and set_format.
> s_stream does not need to be locked; it is called when the pipeline
> is started and thus the link setup can not be changed anymore.
> - Remove the unused g_mbus_config.
>
> This was previously sent as part of Steve's i.MX media series [2].
>
> [1] https://patchwork.kernel.org/patch/9704791/
> [2] https://patchwork.kernel.org/patch/9647869/
> ---
> drivers/media/platform/Kconfig | 6 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/video-mux.c | 312 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 320 insertions(+)
> create mode 100644 drivers/media/platform/video-mux.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c9106e105baba..b046a6d39fee5 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
> To compile this driver as a module, choose M here: the
> module will be called arv.
>
> +config VIDEO_MUX
> + tristate "Video Multiplexer"
> + depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && MULTIPLEXER
> + help
> + This driver provides support for N:1 video bus multiplexers.
> +
> config VIDEO_OMAP3
> tristate "OMAP 3 Camera support"
> depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 349ddf6a69da2..fd2735ca3ff75 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
>
> obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o
>
> +obj-$(CONFIG_VIDEO_MUX) += video-mux.o
> +
> obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
> obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
> obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
> diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
> new file mode 100644
> index 0000000000000..a857f5e89deff
> --- /dev/null
> +++ b/drivers/media/platform/video-mux.c
> @@ -0,0 +1,312 @@
> +/*
> + * video stream multiplexer controlled via mux control
> + *
> + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> + * Copyright (C) 2016-2017 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/mux/consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_graph.h>
> +#include <linux/platform_device.h>
> +#include <media/v4l2-async.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/v4l2-of.h>
Could you rebase this on the V4L2 fwnode patchset here, please?
<URL:https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-acpi>
The conversion is rather simple, as shown here:
<URL:https://git.linuxtv.org/sailus/media_tree.git/commit/?h=v4l2-acpi&id=679035e11bfdbea146fed5d52fb794b34dc9cea6>
> +
> +struct video_mux {
> + struct v4l2_subdev subdev;
> + struct media_pad *pads;
> + struct v4l2_mbus_framefmt *format_mbus;
> + struct v4l2_of_endpoint *endpoint;
> + struct mux_control *mux;
> + struct mutex lock;
> + int active;
> +};
> +
> +static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev *sd)
> +{
> + return container_of(sd, struct video_mux, subdev);
> +}
> +
> +static inline bool is_source_pad(struct video_mux *vmux, unsigned int pad)
It's a common practice to test pad flags rather than the pad number.
Although the pad number here implicitly tells this, too, testing pad flags
is cleaner.
The matter was discussed in the past and it was decided not to add helper
functions to the framework for the purpose as testing the flags is trivial.
> +{
> + return pad == vmux->subdev.entity.num_pads - 1;
> +}
> +
> +static int video_mux_link_setup(struct media_entity *entity,
> + const struct media_pad *local,
> + const struct media_pad *remote, u32 flags)
> +{
> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> + struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
> + int ret = 0;
> +
> + /*
> + * The mux state is determined by the enabled sink pad link.
> + * Enabling or disabling the source pad link has no effect.
> + */
> + if (is_source_pad(vmux, local->index))
> + return 0;
> +
> + dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
> + remote->entity->name, remote->index, local->entity->name,
> + local->index, flags & MEDIA_LNK_FL_ENABLED);
> +
> + mutex_lock(&vmux->lock);
> +
> + if (flags & MEDIA_LNK_FL_ENABLED) {
> + if (vmux->active == local->index)
> + goto out;
> +
> + if (vmux->active >= 0) {
> + ret = -EBUSY;
> + goto out;
> + }
> +
> + dev_dbg(sd->dev, "setting %d active\n", local->index);
> + ret = mux_control_try_select(vmux->mux, local->index);
> + if (ret < 0)
> + goto out;
> + vmux->active = local->index;
> + } else {
> + if (vmux->active != local->index)
> + goto out;
> +
> + dev_dbg(sd->dev, "going inactive\n");
> + mux_control_deselect(vmux->mux);
> + vmux->active = -1;
> + }
> +
> +out:
> + mutex_unlock(&vmux->lock);
> + return ret;
> +}
> +
> +static struct media_entity_operations video_mux_ops = {
> + .link_setup = video_mux_link_setup,
> + .link_validate = v4l2_subdev_link_validate,
> +};
> +
> +static bool video_mux_endpoint_disabled(struct device_node *ep)
> +{
> + struct device_node *rpp = of_graph_get_remote_port_parent(ep);
> +
> + return !of_device_is_available(rpp);
> +}
> +
> +static int video_mux_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
> + struct v4l2_subdev *upstream_sd;
> + struct media_pad *pad;
> +
> + if (vmux->active == -1) {
> + dev_err(sd->dev, "Can not start streaming on inactive mux\n");
> + return -EINVAL;
> + }
> +
> + pad = media_entity_remote_pad(&sd->entity.pads[vmux->active]);
> + if (!pad) {
> + dev_err(sd->dev, "Failed to find remote source pad\n");
> + return -ENOLINK;
> + }
> +
> + if (!is_media_entity_v4l2_subdev(pad->entity)) {
> + dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
> + return -ENODEV;
> + }
> +
> + upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
> +
> + return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
> +}
> +
> +static const struct v4l2_subdev_video_ops video_mux_subdev_video_ops = {
> + .s_stream = video_mux_s_stream,
> +};
> +
> +static struct v4l2_mbus_framefmt *
> +__video_mux_get_pad_format(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + unsigned int pad, u32 which)
> +{
> + struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
> +
> + switch (which) {
> + case V4L2_SUBDEV_FORMAT_TRY:
> + return v4l2_subdev_get_try_format(sd, cfg, pad);
> + case V4L2_SUBDEV_FORMAT_ACTIVE:
> + return &vmux->format_mbus[pad];
> + default:
> + return NULL;
> + }
> +}
> +
> +static int video_mux_get_format(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *sdformat)
> +{
> + sdformat->format = *__video_mux_get_pad_format(sd, cfg, sdformat->pad,
> + sdformat->which);
> + return 0;
> +}
> +
> +static int video_mux_set_format(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *sdformat)
> +{
> + struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
> + struct v4l2_mbus_framefmt *mbusformat;
> +
> + mbusformat = __video_mux_get_pad_format(sd, cfg, sdformat->pad,
> + sdformat->which);
> + if (!mbusformat)
> + return -EINVAL;
> +
> + mutex_lock(&vmux->lock);
> +
> + /* Source pad mirrors active sink pad, no limitations on sink pads */
> + if (is_source_pad(vmux, sdformat->pad) && vmux->active >= 0)
> + sdformat->format = vmux->format_mbus[vmux->active];
> +
> + mutex_unlock(&vmux->lock);
> +
> + *mbusformat = sdformat->format;
Shouldn't you do this before releasing the mutex? The assignment won't be
an atomic operation. Same for get_format; you should take the mutex.
> +
> + return 0;
> +}
> +
> +static struct v4l2_subdev_pad_ops video_mux_pad_ops = {
> + .get_fmt = video_mux_get_format,
> + .set_fmt = video_mux_set_format,
> +};
> +
> +static struct v4l2_subdev_ops video_mux_subdev_ops = {
Const for both of the structs?
> + .pad = &video_mux_pad_ops,
> + .video = &video_mux_subdev_video_ops,
> +};
> +
> +static int video_mux_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct device *dev = &pdev->dev;
> + struct v4l2_of_endpoint endpoint;
> + struct device_node *ep;
> + struct video_mux *vmux;
> + unsigned int num_pads = 0;
> + int ret;
> + int i;
> +
> + vmux = devm_kzalloc(dev, sizeof(*vmux), GFP_KERNEL);
> + if (!vmux)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, vmux);
> +
> + v4l2_subdev_init(&vmux->subdev, &video_mux_subdev_ops);
> + snprintf(vmux->subdev.name, sizeof(vmux->subdev.name), "%s", np->name);
> + vmux->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> + vmux->subdev.dev = dev;
> +
> + /*
> + * The largest numbered port is the output port. It determines
> + * total number of pads.
> + */
> + for_each_endpoint_of_node(np, ep) {
> + of_graph_parse_endpoint(ep, &endpoint.base);
> + num_pads = max(num_pads, endpoint.base.port + 1);
> + }
> +
> + if (num_pads < 2) {
> + dev_err(dev, "Not enough ports %d\n", num_pads);
> + return -EINVAL;
> + }
> +
> + vmux->mux = devm_mux_control_get(dev, NULL);
> + if (IS_ERR(vmux->mux)) {
> + ret = PTR_ERR(vmux->mux);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get mux: %d\n", ret);
> + return ret;
> + }
> +
> + mutex_init(&vmux->lock);
> + vmux->active = -1;
> + vmux->pads = devm_kzalloc(dev, sizeof(*vmux->pads) * num_pads,
> + GFP_KERNEL);
> + vmux->format_mbus = devm_kzalloc(dev, sizeof(*vmux->format_mbus) *
> + num_pads, GFP_KERNEL);
> + vmux->endpoint = devm_kzalloc(dev, sizeof(*vmux->endpoint) *
> + (num_pads - 1), GFP_KERNEL);
> +
> + for (i = 0; i < num_pads - 1; i++)
> + vmux->pads[i].flags = MEDIA_PAD_FL_SINK;
> + vmux->pads[num_pads - 1].flags = MEDIA_PAD_FL_SOURCE;
> +
> + vmux->subdev.entity.function = MEDIA_ENT_F_VID_MUX;
> + ret = media_entity_pads_init(&vmux->subdev.entity, num_pads,
> + vmux->pads);
> + if (ret < 0)
> + return ret;
> +
> + vmux->subdev.entity.ops = &video_mux_ops;
> +
> + for_each_endpoint_of_node(np, ep) {
> + v4l2_of_parse_endpoint(ep, &endpoint);
> +
> + if (video_mux_endpoint_disabled(ep)) {
> + dev_dbg(dev, "port %d disabled\n", endpoint.base.port);
> + continue;
> + }
> +
> + vmux->endpoint[endpoint.base.port] = endpoint;
> + }
> +
> + return v4l2_async_register_subdev(&vmux->subdev);
> +}
> +
> +static int video_mux_remove(struct platform_device *pdev)
> +{
> + struct video_mux *vmux = platform_get_drvdata(pdev);
> + struct v4l2_subdev *sd = &vmux->subdev;
> +
> + v4l2_async_unregister_subdev(sd);
> + media_entity_cleanup(&sd->entity);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id video_mux_dt_ids[] = {
> + { .compatible = "video-mux", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, video_mux_dt_ids);
> +
> +static struct platform_driver video_mux_driver = {
> + .probe = video_mux_probe,
> + .remove = video_mux_remove,
> + .driver = {
> + .of_match_table = video_mux_dt_ids,
> + .name = "video-mux",
> + },
> +};
> +
> +module_platform_driver(video_mux_driver);
> +
> +MODULE_DESCRIPTION("video stream multiplexer");
> +MODULE_AUTHOR("Sascha Hauer, Pengutronix");
> +MODULE_AUTHOR("Philipp Zabel, Pengutronix");
> +MODULE_LICENSE("GPL");
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* Re: [PATCH v4 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.
From: Eric Anholt @ 2017-05-03 19:06 UTC (permalink / raw)
To: Daniel Vetter
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Rob Herring,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170502092400.35owmdw2fgf4uquu-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]
Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> writes:
> On Fri, Apr 28, 2017 at 03:42:22PM -0700, Eric Anholt wrote:
>> The FBDEV initialization would throw an error in dmesg, when we just
>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>>
>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>
> With the commit message updated that passing num_connector is the bug that
> throws the error (and not that we set up a no-op fbdev):
>
> Reviewed-by: Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>
>
> Still kinda hoping for a follow-up to entirely get rid fo num_connector in
> the fbdev init funcs.
New commit message:
drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.
There's no sense in having an fbdev if there's no display, since
connectors don't get hotplugged to this hardware. On Cygnus we were
getting a dmesg error from passing in num_connectors (0), when that
argument is supposed to be the maximum number of cloned connectors per
CRTC (1).
Still no drm-misc acks on the other two patches, so I don't think I can
merge them.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33
From: Chen-Yu Tsai @ 2017-05-03 17:13 UTC (permalink / raw)
To: Mylène Josserand
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Linux-ALSA, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20170503135617.25193-2-mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi,
On Wed, May 3, 2017 at 9:56 PM, Mylène Josserand
<mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Add ADC support for the sun8i-codec driver.
>
> This driver uses all the microphones widgets and routes provided by the
> analog part (sun8i-codec-analog).
> Some digital configurations are needed by creating new ADC widgets
> and routes.
>
> Signed-off-by: Mylène Josserand <mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> sound/soc/sunxi/sun8i-codec.c | 80 +++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 78 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
> index 5723c3404f6b..b4938b06acec 100644
> --- a/sound/soc/sunxi/sun8i-codec.c
> +++ b/sound/soc/sunxi/sun8i-codec.c
> @@ -37,9 +37,11 @@
> #define SUN8I_SYSCLK_CTL_SYSCLK_SRC 0
> #define SUN8I_MOD_CLK_ENA 0x010
> #define SUN8I_MOD_CLK_ENA_AIF1 15
> +#define SUN8I_MOD_CLK_ENA_ADC 3
> #define SUN8I_MOD_CLK_ENA_DAC 2
> #define SUN8I_MOD_RST_CTL 0x014
> #define SUN8I_MOD_RST_CTL_AIF1 15
> +#define SUN8I_MOD_RST_CTL_ADC 3
> #define SUN8I_MOD_RST_CTL_DAC 2
> #define SUN8I_SYS_SR_CTRL 0x018
> #define SUN8I_SYS_SR_CTRL_AIF1_FS 12
> @@ -54,9 +56,25 @@
> #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ 4
> #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16 (1 << 4)
> #define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT 2
> +#define SUN8I_AIF1_ADCDAT_CTRL 0x044
> +#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA 15
> +#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA 14
> #define SUN8I_AIF1_DACDAT_CTRL 0x048
> #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA 15
> #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA 14
> +#define SUN8I_AIF1_MXR_SRC 0x04c
> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L 15
> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL 14
> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL 13
> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR 12
> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R 11
> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR 10
> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR 9
> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL 8
> +#define SUN8I_ADC_DIG_CTRL 0x100
> +#define SUN8I_ADC_DIG_CTRL_ENDA 15
The register bit name in the manual is ENAD, as in ENable ADc.
> +#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS 2
> +#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY 1
> #define SUN8I_DAC_DIG_CTRL 0x120
> #define SUN8I_DAC_DIG_CTRL_ENDA 15
> #define SUN8I_DAC_MXR_SRC 0x130
> @@ -276,10 +294,28 @@ static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
> };
>
> +static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
> + SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
> + SUN8I_AIF1_MXR_SRC,
> + SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
> + SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
> + SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
> + SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
> + SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
> + SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
> + SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
> + SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
> + SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
> + SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
> + SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
> +};
This group of mixer controls is only for AIF1 slot 0 capture.
So in fact they should all read "AIF1 Slot 0 Mixer X Capture Switch",
with X replaced by "AIF1 Slot 0", "AIF2", "ADC", and "AIF2 Inv".
This hopefully informs the user that these controls are for the AIF1
slot 0 mixer, and are capture switch from the various sources listed
above.
> +
> static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
> - /* Digital parts of the DACs */
> + /* Digital parts of the DACs and ADC */
> SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
> 0, NULL, 0),
> + SND_SOC_DAPM_SUPPLY("ADC", SUN8I_ADC_DIG_CTRL, SUN8I_ADC_DIG_CTRL_ENDA,
> + 0, NULL, 0),
>
> /* Analog DAC AIF */
> SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left", "Playback", 0,
> @@ -289,17 +325,31 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
> SUN8I_AIF1_DACDAT_CTRL,
> SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
>
> - /* DAC Mixers */
> + /* Analog ADC AIF */
> + SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left ADC", "Capture", 0,
> + SUN8I_AIF1_ADCDAT_CTRL,
> + SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA, 0),
> + SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Right ADC", "Capture", 0,
> + SUN8I_AIF1_ADCDAT_CTRL,
> + SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA, 0),
You want to use SND_SOC_DAPM_AIF_OUT here, for captured audio out of
the codec and to the system. These are the last widgets in the capture
path.
> +
> + /* DAC and ADC Mixers */
> SOC_MIXER_ARRAY("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
> sun8i_dac_mixer_controls),
> SOC_MIXER_ARRAY("Right Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
> sun8i_dac_mixer_controls),
> + SOC_MIXER_ARRAY("Left Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
> + sun8i_input_mixer_controls),
> + SOC_MIXER_ARRAY("Right Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
> + sun8i_input_mixer_controls),
And these should read "AIF1 Slot 0 Left/Right Mixer".
>
> /* Clocks */
> SND_SOC_DAPM_SUPPLY("MODCLK AFI1", SUN8I_MOD_CLK_ENA,
> SUN8I_MOD_CLK_ENA_AIF1, 0, NULL, 0),
> SND_SOC_DAPM_SUPPLY("MODCLK DAC", SUN8I_MOD_CLK_ENA,
> SUN8I_MOD_CLK_ENA_DAC, 0, NULL, 0),
> + SND_SOC_DAPM_SUPPLY("MODCLK ADC", SUN8I_MOD_CLK_ENA,
> + SUN8I_MOD_CLK_ENA_ADC, 0, NULL, 0),
> SND_SOC_DAPM_SUPPLY("AIF1", SUN8I_SYSCLK_CTL,
> SUN8I_SYSCLK_CTL_AIF1CLK_ENA, 0, NULL, 0),
> SND_SOC_DAPM_SUPPLY("SYSCLK", SUN8I_SYSCLK_CTL,
> @@ -316,6 +366,12 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
> SUN8I_MOD_RST_CTL_AIF1, 0, NULL, 0),
> SND_SOC_DAPM_SUPPLY("RST DAC", SUN8I_MOD_RST_CTL,
> SUN8I_MOD_RST_CTL_DAC, 0, NULL, 0),
> + SND_SOC_DAPM_SUPPLY("RST ADC", SUN8I_MOD_RST_CTL,
> + SUN8I_MOD_RST_CTL_ADC, 0, NULL, 0),
> +
> + SND_SOC_DAPM_MIC("Headset Mic", NULL),
> + SND_SOC_DAPM_MIC("Mic", NULL),
These Mics are board level widgets. Since you are using simple-card,
you should add them in the device tree in the simple-card device
node, using the "simple-audio-card,widgets" property.
You probably should have done so for the output side as well.
If simple-card were fully-routed, the existing device tree simply
wouldn't work.
> +
> };
>
> static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
> @@ -325,11 +381,16 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
> { "RST AIF1", NULL, "AIF1 PLL" },
> { "MODCLK AFI1", NULL, "RST AIF1" },
> { "DAC", NULL, "MODCLK AFI1" },
> + { "ADC", NULL, "MODCLK AFI1" },
This makes no sense. Why would AIF1's module clock feed the ADC? Same goes
for the existing DAC route.
>
> { "RST DAC", NULL, "SYSCLK" },
> { "MODCLK DAC", NULL, "RST DAC" },
> { "DAC", NULL, "MODCLK DAC" },
>
> + { "RST ADC", NULL, "SYSCLK" },
> + { "MODCLK ADC", NULL, "RST ADC" },
> + { "ADC", NULL, "MODCLK ADC" },
This makes little sense either. The SYSCLK probably feeds the ADC's
module clock.
The MODCLK then feeds the ADC. The ADC reset feeds the ADC (or rather the ADC
depends on its reset). The "ADC" widget here is actually just the enable switch.
But we can use it as a kind of placeholder, to setup the dependencies correctly.
I wish we had named the widgets better, but alas they are part of the
device tree
binding, even though they are not documented, so we can not change the existing
ones.
> +
> /* DAC Routes */
> { "AIF1 Slot 0 Right", NULL, "DAC" },
> { "AIF1 Slot 0 Left", NULL, "DAC" },
> @@ -339,6 +400,12 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
> "AIF1 Slot 0 Left"},
> { "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
> "AIF1 Slot 0 Right"},
> +
> + /* ADC routes */
> + { "Left Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
> + "AIF1 Slot 0 Left ADC" },
> + { "Right Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
> + "AIF1 Slot 0 Right ADC" },
Same thing about the "ADC Mixer" names.
And these routes are completely backwards. "AIF1 Slot 0 Left/Right ADC" are
the output stream widgets. They are fed from "AIF1 Slot 0 Left/Right Mixer"
if you use the names I suggested, or "Left/Right Digital ADC Mixer" originally.
You then need other routes feeding the mixer. Looks like you also need ADC
placeholder widgets on the digital side here, so you can hook up the analog
side in simple-card more easily.
If you can, please dump the DAPM routes into a directed graph to check
everything
is connected and makes sense. I believe you have a script that does this.
Regards
ChenYu
> };
>
> static struct snd_soc_dai_ops sun8i_codec_dai_ops = {
> @@ -356,6 +423,15 @@ static struct snd_soc_dai_driver sun8i_codec_dai = {
> .rates = SNDRV_PCM_RATE_8000_192000,
> .formats = SNDRV_PCM_FMTBIT_S16_LE,
> },
> + /* capture capabilities */
> + .capture = {
> + .stream_name = "Capture",
> + .channels_min = 1,
> + .channels_max = 2,
> + .rates = SNDRV_PCM_RATE_8000_192000,
> + .formats = SNDRV_PCM_FMTBIT_S16_LE,
> + .sig_bits = 24,
> + },
> /* pcm operations */
> .ops = &sun8i_codec_dai_ops,
> };
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] driver: input :touchscreen : Change Raydium firmware update parameter
From: Guenter Roeck @ 2017-05-03 15:55 UTC (permalink / raw)
To: jeffrey.lin
Cc: Dmitry Torokhov, bleung, Guenter Roeck, Katherine.Hsieh,
Jeffrey Lin, ealin.chiu, calvin.tseng, KP.li, albert.shieh,
linux-kernel, linux-input, devicetree, jeffrey.lin
In-Reply-To: <20170503153717.328-1-jeffrey.lin@rad-ic.com>
On Wed, May 3, 2017 at 8:37 AM, jeffrey.lin <yajohn@gmail.com> wrote:
> From: "jeffrey.lin" <jeffrey.lin@raydium.corp-partner.google.com>
>
> Change boot mode trigger parameter of Raydium firmware update.
>
That is a bit vague. What is changed to what, and why ?
In other words, what prevents someone else from changing it back to
the old value, using the same description ?
> Signed-off-by: jeffrey.lin <jeffrey.lin@rad-ic.com>
> ---
> drivers/input/touchscreen/raydium_i2c_ts.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c b/drivers/input/touchscreen/raydium_i2c_ts.c
> index a99fb5cac5a0..8a81257634ba 100644
> --- a/drivers/input/touchscreen/raydium_i2c_ts.c
> +++ b/drivers/input/touchscreen/raydium_i2c_ts.c
> @@ -450,7 +450,7 @@ static bool raydium_i2c_boot_trigger(struct i2c_client *client)
> { 0x08, 0x04, 0x09, 0x00, 0x50, 0xA5 },
> { 0x08, 0x0C, 0x09, 0x00, 0x50, 0x00 },
> { 0x06, 0x01, 0x00, 0x00, 0x00, 0x00 },
> - { 0x02, 0xA2, 0x00, 0x00, 0x00, 0x00 },
> + { 0x02, 0xA1, 0x00, 0x00, 0x00, 0x00 },
> };
> int i;
> int error;
> @@ -1199,7 +1199,7 @@ static SIMPLE_DEV_PM_OPS(raydium_i2c_pm_ops,
> raydium_i2c_suspend, raydium_i2c_resume);
>
> static const struct i2c_device_id raydium_i2c_id[] = {
> - { "raydium_i2c" , 0 },
> + { "raydium_i2c", 0 },
Unrelated whitespace change.
> { "rm32380", 0 },
> { /* sentinel */ }
> };
> --
> 2.12.2
>
^ permalink raw reply
* [PATCH] driver: input :touchscreen : Change Raydium firmware update parameter
From: jeffrey.lin @ 2017-05-03 15:37 UTC (permalink / raw)
To: dmitry.torokhov, bleung, groeck, Katherine.Hsieh
Cc: jeffrey.lin, ealin.chiu, calvin.tseng, KP.li, albert.shieh,
linux-kernel, linux-input, devicetree, jeffrey.lin
From: "jeffrey.lin" <jeffrey.lin@raydium.corp-partner.google.com>
Change boot mode trigger parameter of Raydium firmware update.
Signed-off-by: jeffrey.lin <jeffrey.lin@rad-ic.com>
---
drivers/input/touchscreen/raydium_i2c_ts.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c b/drivers/input/touchscreen/raydium_i2c_ts.c
index a99fb5cac5a0..8a81257634ba 100644
--- a/drivers/input/touchscreen/raydium_i2c_ts.c
+++ b/drivers/input/touchscreen/raydium_i2c_ts.c
@@ -450,7 +450,7 @@ static bool raydium_i2c_boot_trigger(struct i2c_client *client)
{ 0x08, 0x04, 0x09, 0x00, 0x50, 0xA5 },
{ 0x08, 0x0C, 0x09, 0x00, 0x50, 0x00 },
{ 0x06, 0x01, 0x00, 0x00, 0x00, 0x00 },
- { 0x02, 0xA2, 0x00, 0x00, 0x00, 0x00 },
+ { 0x02, 0xA1, 0x00, 0x00, 0x00, 0x00 },
};
int i;
int error;
@@ -1199,7 +1199,7 @@ static SIMPLE_DEV_PM_OPS(raydium_i2c_pm_ops,
raydium_i2c_suspend, raydium_i2c_resume);
static const struct i2c_device_id raydium_i2c_id[] = {
- { "raydium_i2c" , 0 },
+ { "raydium_i2c", 0 },
{ "rm32380", 0 },
{ /* sentinel */ }
};
--
2.12.2
^ permalink raw reply related
* [PATCH] ARM: dts: imx: add DH2228FV DAC to Gateworks Ventana boards with SPI
From: Tim Harvey @ 2017-05-03 15:04 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 6 ++++++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 6 ++++++
arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 6 ++++++
3 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index 91991d6..b5c1a8f 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -143,6 +143,12 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi3>;
status = "okay";
+
+ spidev0: spidev@0 {
+ compatible = "rohm,dh2228fv";
+ reg = <0>;
+ spi-max-frequency = <60000000>;
+ };
};
&fec {
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 968fda9..9d26511 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -154,6 +154,12 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi2>;
status = "okay";
+
+ spidev0: spidev@0 {
+ compatible = "rohm,dh2228fv";
+ reg = <0>;
+ spi-max-frequency = <60000000>;
+ };
};
&fec {
diff --git a/arch/arm/boot/dts/imx6qdl-gw560x.dtsi b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
index d894dde..bfb63e9 100644
--- a/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
@@ -208,6 +208,12 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ecspi3>;
status = "okay";
+
+ spidev0: spidev@0 {
+ compatible = "rohm,dh2228fv";
+ reg = <0>;
+ spi-max-frequency = <60000000>;
+ };
};
&can1 {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 3/3] backlight arcxcnn add support for ArcticSand devices
From: Olimpiu Dejeu @ 2017-05-03 15:04 UTC (permalink / raw)
To: robh
Cc: lee.jones, linux-kernel, linux-fbdev, devicetree, jingoohan1,
bdodge, joe, daniel.thompson, lkp, fengguang.wu, Olimpiu Dejeu
In-Reply-To: <1493823859-22402-1-git-send-email-olimpiu@arcticsand.com>
backlight: Add support for Arctic Sand LED backlight driver chips
This driver provides support for the Arctic Sand arc2c0608 chip,
and provides a framework to support future devices.
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
---
v9 => v10:
- Per Rob Herring's request changed vendor-prefix to arctic
v8 => v9:
- Addressing kbuild test robot WARNING: PTR_ERR_OR_ZERO can be used
v7 => v8:
- Version updated to match other patch in set. No other changes.
v6 => v7:
- Addressing issues brought up by Daniel Thompson
v5 => v6:
- Addressing issues brought up by Daniel Thompson
v4 => v5:
- Code style changes per Joe Perches and Jingoo Han
v3 => v4:
- Code style changes per Joe Perches and Jingoo Han
v2 => v3:
- Renamed variables to comply with conventions on naming
- Corrected device name in arcxcnn.h
v1 => v2:
- Removed "magic numbers" to initialize registers
- Cleaned up device tree bindings
- Fixed code style to address comments and pass "checkpatch"
- Removed unneeded debug and testing code
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/arcxcnn_bl.c | 419 +++++++++++++++++++++++++++++++++++
3 files changed, 427 insertions(+)
create mode 100644 drivers/video/backlight/arcxcnn_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ffa4b4..4e1d2ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -460,6 +460,13 @@ config BACKLIGHT_BD6107
help
If you have a Rohm BD6107 say Y to enable the backlight driver.
+config BACKLIGHT_ARCXCNN
+ tristate "Backlight driver for the Arctic Sands ARCxCnnnn family"
+ depends on I2C
+ help
+ If you have an ARCxCnnnn family backlight say Y to enable
+ the backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 16ec534..8905129 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
+obj-$(CONFIG_BACKLIGHT_ARCXCNN) += arcxcnn_bl.o
diff --git a/drivers/video/backlight/arcxcnn_bl.c b/drivers/video/backlight/arcxcnn_bl.c
new file mode 100644
index 0000000..e01b1b0
--- /dev/null
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -0,0 +1,419 @@
+/*
+ * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ * Author : Brian Dodge <bdodge@arcticsand.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/backlight.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+enum arcxcnn_chip_id {
+ ARC2C0608
+};
+
+/**
+ * struct arcxcnn_platform_data
+ * @name : Backlight driver name (NULL will use default)
+ * @initial_brightness : initial value of backlight brightness
+ * @leden : initial LED string enables, upper bit is global on/off
+ * @led_config_0 : fading speed (period between intensity steps)
+ * @led_config_1 : misc settings, see datasheet
+ * @dim_freq : pwm dimming frequency if in pwm mode
+ * @comp_config : misc config, see datasheet
+ * @filter_config : RC/PWM filter config, see datasheet
+ * @trim_config : full scale current trim, see datasheet
+ */
+struct arcxcnn_platform_data {
+ const char *name;
+ u16 initial_brightness;
+ u8 leden;
+ u8 led_config_0;
+ u8 led_config_1;
+ u8 dim_freq;
+ u8 comp_config;
+ u8 filter_config;
+ u8 trim_config;
+};
+
+#define ARCXCNN_CMD 0x00 /* Command Register */
+#define ARCXCNN_CMD_STDBY 0x80 /* I2C Standby */
+#define ARCXCNN_CMD_RESET 0x40 /* Reset */
+#define ARCXCNN_CMD_BOOST 0x10 /* Boost */
+#define ARCXCNN_CMD_OVP_MASK 0x0C /* --- Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_XXV 0x0C /* <rsvrd> Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_20V 0x08 /* 20v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_24V 0x04 /* 24v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_31V 0x00 /* 31.4v Over Voltage Threshold */
+#define ARCXCNN_CMD_EXT_COMP 0x01 /* part (0) or full (1) ext. comp */
+
+#define ARCXCNN_CONFIG 0x01 /* Configuration */
+#define ARCXCNN_STATUS1 0x02 /* Status 1 */
+#define ARCXCNN_STATUS2 0x03 /* Status 2 */
+#define ARCXCNN_FADECTRL 0x04 /* Fading Control */
+#define ARCXCNN_ILED_CONFIG 0x05 /* ILED Configuration */
+#define ARCXCNN_ILED_DIM_PWM 0x00 /* config dim mode pwm */
+#define ARCXCNN_ILED_DIM_INT 0x04 /* config dim mode internal */
+#define ARCXCNN_LEDEN 0x06 /* LED Enable Register */
+#define ARCXCNN_LEDEN_ISETEXT 0x80 /* Full-scale current set extern */
+#define ARCXCNN_LEDEN_MASK 0x3F /* LED string enables mask */
+#define ARCXCNN_LEDEN_BITS 0x06 /* Bits of LED string enables */
+#define ARCXCNN_LEDEN_LED1 0x01
+#define ARCXCNN_LEDEN_LED2 0x02
+#define ARCXCNN_LEDEN_LED3 0x04
+#define ARCXCNN_LEDEN_LED4 0x08
+#define ARCXCNN_LEDEN_LED5 0x10
+#define ARCXCNN_LEDEN_LED6 0x20
+
+#define ARCXCNN_WLED_ISET_LSB 0x07 /* LED ISET LSB (in upper nibble) */
+#define ARCXCNN_WLED_ISET_LSB_SHIFT 0x04 /* ISET LSB Left Shift */
+#define ARCXCNN_WLED_ISET_MSB 0x08 /* LED ISET MSB (8 bits) */
+
+#define ARCXCNN_DIMFREQ 0x09
+#define ARCXCNN_COMP_CONFIG 0x0A
+#define ARCXCNN_FILT_CONFIG 0x0B
+#define ARCXCNN_IMAXTUNE 0x0C
+#define ARCXCNN_ID_MSB 0x1E
+#define ARCXCNN_ID_LSB 0x1F
+
+#define MAX_BRIGHTNESS 4095
+#define INIT_BRIGHT 60
+
+struct arcxcnn {
+ struct i2c_client *client;
+ struct backlight_device *bl;
+ struct device *dev;
+ struct arcxcnn_platform_data *pdata;
+};
+
+static int arcxcnn_update_field(struct arcxcnn *lp, u8 reg, u8 mask, u8 data)
+{
+ int ret;
+ u8 tmp;
+
+ ret = i2c_smbus_read_byte_data(lp->client, reg);
+ if (ret < 0) {
+ dev_err(lp->dev, "failed to read 0x%.2x\n", reg);
+ return ret;
+ }
+
+ tmp = (u8)ret;
+ tmp &= ~mask;
+ tmp |= data & mask;
+
+ return i2c_smbus_write_byte_data(lp->client, reg, tmp);
+}
+
+static int arcxcnn_set_brightness(struct arcxcnn *lp, u32 brightness)
+{
+ int ret;
+ u8 val;
+
+ /* lower nibble of brightness goes in upper nibble of LSB register */
+ val = (brightness & 0xF) << ARCXCNN_WLED_ISET_LSB_SHIFT;
+ ret = i2c_smbus_write_byte_data(lp->client,
+ ARCXCNN_WLED_ISET_LSB, val);
+ if (ret < 0)
+ return ret;
+
+ /* remaining 8 bits of brightness go in MSB register */
+ val = (brightness >> 4);
+ return i2c_smbus_write_byte_data(lp->client,
+ ARCXCNN_WLED_ISET_MSB, val);
+}
+
+static int arcxcnn_bl_update_status(struct backlight_device *bl)
+{
+ struct arcxcnn *lp = bl_get_data(bl);
+ u32 brightness = bl->props.brightness;
+ int ret;
+
+ if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ brightness = 0;
+
+ ret = arcxcnn_set_brightness(lp, brightness);
+ if (ret)
+ return ret;
+
+ /* set power-on/off/save modes */
+ return arcxcnn_update_field(lp, ARCXCNN_CMD, ARCXCNN_CMD_STDBY,
+ (bl->props.power == 0) ? 0 : ARCXCNN_CMD_STDBY);
+}
+
+static const struct backlight_ops arcxcnn_bl_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = arcxcnn_bl_update_status,
+};
+
+static int arcxcnn_backlight_register(struct arcxcnn *lp)
+{
+ struct backlight_properties *props;
+ const char *name = lp->pdata->name ? : "arctic_bl";
+
+ props = devm_kzalloc(lp->dev, sizeof(*props), GFP_KERNEL);
+ if (!props)
+ return -ENOMEM;
+
+ props->type = BACKLIGHT_PLATFORM;
+ props->max_brightness = MAX_BRIGHTNESS;
+
+ if (lp->pdata->initial_brightness > props->max_brightness)
+ lp->pdata->initial_brightness = props->max_brightness;
+
+ props->brightness = lp->pdata->initial_brightness;
+
+ lp->bl = devm_backlight_device_register(lp->dev, name, lp->dev, lp,
+ &arcxcnn_bl_ops, props);
+ return PTR_ERR_OR_ZERO(lp->bl);
+}
+
+static void arcxcnn_parse_dt(struct arcxcnn *lp)
+{
+ struct device *dev = lp->dev;
+ struct device_node *node = dev->of_node;
+ u32 prog_val, num_entry, entry, sources[ARCXCNN_LEDEN_BITS];
+ int ret;
+
+ /* device tree entry isn't required, defaults are OK */
+ if (!node)
+ return;
+
+ ret = of_property_read_string(node, "label", &lp->pdata->name);
+ if (ret < 0)
+ lp->pdata->name = NULL;
+
+ ret = of_property_read_u32(node, "default-brightness", &prog_val);
+ if (ret == 0)
+ lp->pdata->initial_brightness = prog_val;
+
+ ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
+ if (ret == 0)
+ lp->pdata->led_config_0 = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arctic,led-config-1", &prog_val);
+ if (ret == 0)
+ lp->pdata->led_config_1 = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arctic,dim-freq", &prog_val);
+ if (ret == 0)
+ lp->pdata->dim_freq = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arctic,comp-config", &prog_val);
+ if (ret == 0)
+ lp->pdata->comp_config = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arctic,filter-config", &prog_val);
+ if (ret == 0)
+ lp->pdata->filter_config = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arctic,trim-config", &prog_val);
+ if (ret == 0)
+ lp->pdata->trim_config = (u8)prog_val;
+
+ ret = of_property_count_u32_elems(node, "led-sources");
+ if (ret < 0) {
+ lp->pdata->leden = ARCXCNN_LEDEN_MASK; /* all on is default */
+ } else {
+ num_entry = ret;
+ if (num_entry > ARCXCNN_LEDEN_BITS)
+ num_entry = ARCXCNN_LEDEN_BITS;
+
+ ret = of_property_read_u32_array(node, "led-sources", sources,
+ num_entry);
+ if (ret < 0) {
+ dev_err(dev, "led-sources node is invalid.\n");
+ return;
+ }
+
+ lp->pdata->leden = 0;
+
+ /* for each enable in source, set bit in led enable */
+ for (entry = 0; entry < num_entry; entry++) {
+ u8 onbit = 1 << sources[entry];
+
+ lp->pdata->leden |= onbit;
+ }
+ }
+}
+
+static int arcxcnn_probe(struct i2c_client *cl, const struct i2c_device_id *id)
+{
+ struct arcxcnn *lp;
+ int ret;
+
+ if (!i2c_check_functionality(cl->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -EIO;
+
+ lp = devm_kzalloc(&cl->dev, sizeof(*lp), GFP_KERNEL);
+ if (!lp)
+ return -ENOMEM;
+
+ lp->client = cl;
+ lp->dev = &cl->dev;
+ lp->pdata = dev_get_platdata(&cl->dev);
+
+ /* reset the device */
+ ret = i2c_smbus_write_byte_data(lp->client,
+ ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+ if (ret)
+ goto probe_err;
+
+ if (!lp->pdata) {
+ lp->pdata = devm_kzalloc(lp->dev,
+ sizeof(*lp->pdata), GFP_KERNEL);
+ if (!lp->pdata)
+ return -ENOMEM;
+
+ /* Setup defaults based on power-on defaults */
+ lp->pdata->name = NULL;
+ lp->pdata->initial_brightness = INIT_BRIGHT;
+ lp->pdata->leden = ARCXCNN_LEDEN_MASK;
+
+ lp->pdata->led_config_0 = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_FADECTRL);
+
+ lp->pdata->led_config_1 = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_ILED_CONFIG);
+ /* insure dim mode is not default pwm */
+ lp->pdata->led_config_1 |= ARCXCNN_ILED_DIM_INT;
+
+ lp->pdata->dim_freq = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_DIMFREQ);
+
+ lp->pdata->comp_config = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_COMP_CONFIG);
+
+ lp->pdata->filter_config = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_FILT_CONFIG);
+
+ lp->pdata->trim_config = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_IMAXTUNE);
+
+ if (IS_ENABLED(CONFIG_OF))
+ arcxcnn_parse_dt(lp);
+ }
+
+ i2c_set_clientdata(cl, lp);
+
+ /* constrain settings to what is possible */
+ if (lp->pdata->initial_brightness > MAX_BRIGHTNESS)
+ lp->pdata->initial_brightness = MAX_BRIGHTNESS;
+
+ /* set initial brightness */
+ ret = arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
+ if (ret)
+ goto probe_err;
+
+ /* set other register values directly */
+ ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_FADECTRL,
+ lp->pdata->led_config_0);
+ if (ret)
+ goto probe_err;
+
+ ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_ILED_CONFIG,
+ lp->pdata->led_config_1);
+ if (ret)
+ goto probe_err;
+
+ ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_DIMFREQ,
+ lp->pdata->dim_freq);
+ if (ret)
+ goto probe_err;
+
+ ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_COMP_CONFIG,
+ lp->pdata->comp_config);
+ if (ret)
+ goto probe_err;
+
+ ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_FILT_CONFIG,
+ lp->pdata->filter_config);
+ if (ret)
+ goto probe_err;
+
+ ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_IMAXTUNE,
+ lp->pdata->trim_config);
+ if (ret)
+ goto probe_err;
+
+ /* set initial LED Enables */
+ arcxcnn_update_field(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->leden);
+
+ ret = arcxcnn_backlight_register(lp);
+ if (ret)
+ goto probe_register_err;
+
+ backlight_update_status(lp->bl);
+
+ return 0;
+
+probe_register_err:
+ dev_err(lp->dev,
+ "failed to register backlight.\n");
+
+probe_err:
+ dev_err(lp->dev,
+ "failure ret: %d\n", ret);
+ return ret;
+}
+
+static int arcxcnn_remove(struct i2c_client *cl)
+{
+ struct arcxcnn *lp = i2c_get_clientdata(cl);
+
+ /* disable all strings (ignore errors) */
+ i2c_smbus_write_byte_data(lp->client,
+ ARCXCNN_LEDEN, 0x00);
+ /* reset the device (ignore errors) */
+ i2c_smbus_write_byte_data(lp->client,
+ ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+
+ lp->bl->props.brightness = 0;
+
+ backlight_update_status(lp->bl);
+
+ return 0;
+}
+
+static const struct of_device_id arcxcnn_dt_ids[] = {
+ { .compatible = "arctic,arc2c0608" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, arcxcnn_dt_ids);
+
+static const struct i2c_device_id arcxcnn_ids[] = {
+ {"arc2c0608", ARC2C0608},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, arcxcnn_ids);
+
+static struct i2c_driver arcxcnn_driver = {
+ .driver = {
+ .name = "arcxcnn_bl",
+ .of_match_table = of_match_ptr(arcxcnn_dt_ids),
+ },
+ .probe = arcxcnn_probe,
+ .remove = arcxcnn_remove,
+ .id_table = arcxcnn_ids,
+};
+module_i2c_driver(arcxcnn_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Brian Dodge <bdodge@arcticsand.com>");
+MODULE_DESCRIPTION("ARCXCNN Backlight driver");
--
2.7.4
^ permalink raw reply related
* [PATCH v10 2/3] backlight arcxcnn devicetree bindings for ArcticSand
From: Olimpiu Dejeu @ 2017-05-03 15:04 UTC (permalink / raw)
To: robh
Cc: lee.jones, linux-kernel, linux-fbdev, devicetree, jingoohan1,
bdodge, joe, daniel.thompson, lkp, fengguang.wu, Olimpiu Dejeu
In-Reply-To: <1493823859-22402-1-git-send-email-olimpiu@arcticsand.com>
backlight: Add devicetree bindings for the Arctic Sand backlight driver
This patch provides devicetree bindings for the Arctic Sand
driver submitted in the previous patch
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
---
v9 => v10:
- Per Rob Herring's request changed vendor-prefix to arctic
v8 => v9:
- Version updated to match other patch in set. No other changes.
v7 => v8:
- Version updated to match other patch in set. No other changes.
v6 => v7:
- Version updated to match other patch in set. No other changes.
v5 => v6:
- Version updated to match other patch in set. No other changes.
v4 => v5:
- Added spaces for increased readability per Lee Jones
v3 => v4:
- Added spaces for increased readability per Lee Jones
v2 => v3:
- Version updated to match other patch in set. No other changes.
v1 => v2:
- Version updated to match other patch in set. No other changes.
.../bindings/leds/backlight/arcxcnn_bl.txt | 33 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
new file mode 100644
index 0000000..ecb7731
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -0,0 +1,33 @@
+Binding for ArcticSand arc2c0608 LED driver
+
+Required properties:
+- compatible: should be "arctic,arc2c0608"
+- reg: slave address
+
+Optional properties:
+- default-brightness: brightness value on boot, value from: 0-4095
+- label: The name of the backlight device
+ See Documentation/devicetree/bindings/leds/common.txt
+- led-sources: List of enabled channels from 0 to 5.
+ See Documentation/devicetree/bindings/leds/common.txt
+
+- arctic,led-config-0: setting for register ILED_CONFIG_0
+- arctic,led-config-1: setting for register ILED_CONFIG_1
+- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
+- arctic,comp-config: setting for register CONFIG_COMP
+- arctic,filter-config: setting for register FILTER_CONFIG
+- arctic,trim-config: setting for register IMAXTUNE
+
+Note: Optional properties not specified will default to values in IC EPROM
+
+Example:
+
+arc2c0608@30 {
+ compatible = "arctic,arc2c0608";
+ reg = <0x30>;
+ default-brightness = <500>;
+ label = "lcd-backlight";
+ linux,default-trigger = "backlight";
+ led-sources = <0 1 2 5>;
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH v10 1/3] backlight arcxcnn add arc to vendor prefix
From: Olimpiu Dejeu @ 2017-05-03 15:04 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, bdodge-eV7fy4qpoLhpLGFMi4vTTA,
joe-6d6DIl74uiNBDgjK7y7TUQ,
daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
lkp-ral2JQCrhuEAvxtiuMwx3w, fengguang.wu-ral2JQCrhuEAvxtiuMwx3w,
Olimpiu Dejeu
backlight: Add arc to vendor prefixes
Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
---
v9 => v10:
- Per Rob Herring's request changed vendor-prefix to arctic
v8 => v9:
- Version updated to match other patch in set. No other changes.
v8:
- Version to match other patches in set
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e..6f33a4b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -28,6 +28,7 @@ andestech Andes Technology Corporation
apm Applied Micro Circuits Corporation (APM)
aptina Aptina Imaging
arasan Arasan Chip Systems
+arctic Arctic Sand
aries Aries Embedded GmbH
arm ARM Ltd.
armadeus ARMadeus Systems SARL
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re:What has actually kept you waiting?
From: Mr.Williams Brown @ 2017-05-03 14:46 UTC (permalink / raw)
What has actually kept you waiting to claim your fund $870.000.00 since then?
Your fund has been approved since and nobody has heard from you.
hurry and get back to me with your valid receiving data immediately you receive this mail to avoid error procedures because the United Nation Newly Elected president has approved the release of your awaited funds.
Regards,
Mr. Williams Brown.
CUSTOMER CARE ON FOREIGN PAYMENT.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH][v2] arm64: dts: ls2081ardb: Add DTS support for NXP LS2081ARDB
From: Shawn Guo @ 2017-05-03 14:31 UTC (permalink / raw)
To: Priyanka Jain
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, leoyang.li-3arQi8VN3Tc,
stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
scott.wood-3arQi8VN3Tc
In-Reply-To: <1493367930-10612-1-git-send-email-priyanka.jain-3arQi8VN3Tc@public.gmane.org>
On Fri, Apr 28, 2017 at 01:55:30PM +0530, Priyanka Jain wrote:
> This patch add support for NXP LS2081ARDB board which has
> LS2081A SoC.
>
> LS2081A SoC is 40-pin derivative of LS2088A SoC
> So, from functional perspective both are same.
> Hence,ls2088a SoC dtsi files are included from ls2081ARDB dts
>
> Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
> ---
> Changes for v2: Updated subject and NXP copyright
> based on Leo's comments
>
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts | 139 +++++++++++++++++++++
> 2 files changed, 140 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 72c4b52..58b80de 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2081a-rdb.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
> dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> new file mode 100644
> index 0000000..bc1c4f6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> @@ -0,0 +1,139 @@
> +/*
> + * Device Tree file for NXP LS2081A RDB Board.
> + *
> + * Copyright 2017, NXP
It still doesn't match what Leo's patch does.
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt64&id=827270124c75c7eca8d2e0b41e21fc668e04932e
Hint: there is no comma in the middle.
> + *
> + * Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "fsl-ls2088a.dtsi"
> +
> +/ {
> + model = "NXP Layerscape 2081A RDB Board";
> + compatible = "fsl,ls2081a-rdb", "fsl,ls2081a";
> +
> + aliases {
> + serial0 = &serial0;
> + serial1 = &serial1;
> + };
> +
> + chosen {
> + stdout-path = "serial1:115200n8";
> + };
> +};
> +
> +&esdhc {
> + status = "okay";
> +};
> +
> +&ifc {
> + status = "disabled";
We should have those devices which will need board level connector/pinout
disabled in <soc>.dtsi, and enable the device in <board>.dts which
actually has the device pinout on board.
> +};
> +
> +&i2c0 {
> + status = "okay";
Have a newline between property list and child node.
> + pca9547@75 {
Node name should be as generic as possible. The name used in bindings
doc example is obviously better.
This comment applies to other nodes added by this patch.
> + compatible = "nxp,pca9547";
> + reg = <0x75>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + i2c@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x01>;
> + rtc@51 {
> + compatible = "nxp,pcf2129";
> + reg = <0x51>;
> + };
> + };
> +
> + i2c@3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x3>;
> +
> + adt7481@4c {
> + compatible = "adi,adt7461";
> + reg = <0x4c>;
> + };
> + };
> + };
> +};
> +
> +&dspi {
Sort these labeled nodes alphabetically.
> + status = "okay";
> + dflash0: n25q512a {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80";
> + spi-max-frequency = <3000000>;
> + reg = <0>;
> + };
> +};
> +
> +
> +&qspi {
> + status = "okay";
> + flash0: n25q512a@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
> + };
Have a newline between nodes.
Shawn
> + flash1: n25q512a@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,m25p80";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
> + };
> +};
> +
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> --
> 1.7.4.1
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] ASoC: sunxi: Add ADC support for A33
From: Mylene Josserand @ 2017-05-03 14:02 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, maxime.ripard, wens, robh+dt,
mark.rutland
Cc: devicetree, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20170503135617.25193-1-mylene.josserand@free-electrons.com>
Hello,
On 03/05/2017 15:56, Mylène Josserand wrote:
> Hello everyone,
>
> This is a first version of a serie to add ADC support
> for Sun8i-A33.
> Based on asoc/for-next branch, last commit:
> 20d5c84bef067b7e804a163e2abca16c47125bad.
>
> The first patch adds the support of ADC and microphones in the digital
> part (driver sun8i-codec).
> The second one adds the route between analog (sun8i-codec-analog) and
> digital (sun8i-codec) parts to have a functional ADC route on Sun8i-A33
> device tree.
>
> Tested on Allwinner R16 Parrot board with microphone 1 (external) and
> microphone 2 (headset).
I forgot to add in my cover-letter amixer commands used to test it:
amixer set 'AIF1 Data Digital ADC' cap
amixer set 'Mic1' cap
or
amixer set 'Mic2' cap
and, just in case, the commands to enable output/DAC:
amixer set 'Headphone' 50%
amixer set 'Headphone' on
amixer set 'DAC' on
amixer set 'AIF1 Slot 0 Digital DAC' on
> I am not sure about the bias handling so if you have any comments on it,
> do not hesitate.
>
> Thank you in advance!
>
> Best regards,
>
> Mylène Josserand (2):
> ASoC: sun8i-codec: Add ADC support for a33
> ARM: dts: sun8i: Add ADC routing
>
> arch/arm/boot/dts/sun8i-a33.dtsi | 10 ++++-
> sound/soc/sunxi/sun8i-codec.c | 80 +++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 87 insertions(+), 3 deletions(-)
>
Best regards,
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: dra7: Reduce cpu thermal shutdown temperature
From: Ravikumar @ 2017-05-03 13:57 UTC (permalink / raw)
To: bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170412062442.17736-1-rk-l0cyMroinI0@public.gmane.org>
Hi,
On Wednesday 12 April 2017 11:54 AM, Kattekola, Ravikumar wrote:
> On dra7, as per TRM, the HW shutdown (TSHUT) temperature is hardcoded
> to 123C and cannot be modified by SW. This means when the temperature
> reaches 123C HW asserts TSHUT output which signals a warm reset.
> This reset is held until the temperature goes below the TSHUT low (105C).
>
> While in SW, the thermal driver continuously monitors current temperature
> and takes decisions based on whether it reached an alert or a critical point.
> The intention of setting a SW critical point is to prevent force reset by HW
> and instead do an orderly_poweroff(). But if the SW critical temperature is
> greater than or equal to that of HW then it defeats the purpose. To address
> this and let SW take action before HW does keep the SW critical temperature
> less than HW TSHUT value.
>
> The value for SW critical temperature was chosen as 120C just to ensure
> we give SW sometime before HW catches up.
>
> Document reference
> SPRUI30C – DRA75x, DRA74x Technical Reference Manual - November 2016
> SPRUHZ6H - AM572x Technical Reference Manual - November 2016
>
> Tested on:
> DRA75x PG 2.0 Rev H EVM
>
> Signed-off-by: Ravikumar Kattekola <rk-l0cyMroinI0@public.gmane.org>
> ---
> arch/arm/boot/dts/dra7.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 57892f2..e714466 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -2017,4 +2017,8 @@
> coefficients = <0 2000>;
> };
>
> +&cpu_crit {
> + temperature = <120000>; /* milli Celsius */
> +};
> +
> /include/ "dra7xx-clocks.dtsi"
Ping..
Any comments?
Regards,
RK
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] ARM: dts: sun8i: Add ADC routing
From: Mylène Josserand @ 2017-05-03 13:56 UTC (permalink / raw)
To: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20170503135617.25193-1-mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Add the ADC route between the analog and the digital parts
of sun8i A33. Configure the MIC1 to use MBIAS and MIC2 to use HBIAS.
Signed-off-by: Mylène Josserand <mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a33.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 306af6cadf26..0d3f7b5a23ef 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -114,7 +114,15 @@
simple-audio-card,aux-devs = <&codec_analog>;
simple-audio-card,routing =
"Left DAC", "AIF1 Slot 0 Left",
- "Right DAC", "AIF1 Slot 0 Right";
+ "Right DAC", "AIF1 Slot 0 Right",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Mic", "MBIAS",
+ "Headset Mic", "HBIAS",
+ "MIC1", "Mic",
+ "MIC2", "Headset Mic";
status = "disabled";
simple-audio-card,cpu {
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33
From: Mylène Josserand @ 2017-05-03 13:56 UTC (permalink / raw)
To: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20170503135617.25193-1-mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Add ADC support for the sun8i-codec driver.
This driver uses all the microphones widgets and routes provided by the
analog part (sun8i-codec-analog).
Some digital configurations are needed by creating new ADC widgets
and routes.
Signed-off-by: Mylène Josserand <mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
sound/soc/sunxi/sun8i-codec.c | 80 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index 5723c3404f6b..b4938b06acec 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -37,9 +37,11 @@
#define SUN8I_SYSCLK_CTL_SYSCLK_SRC 0
#define SUN8I_MOD_CLK_ENA 0x010
#define SUN8I_MOD_CLK_ENA_AIF1 15
+#define SUN8I_MOD_CLK_ENA_ADC 3
#define SUN8I_MOD_CLK_ENA_DAC 2
#define SUN8I_MOD_RST_CTL 0x014
#define SUN8I_MOD_RST_CTL_AIF1 15
+#define SUN8I_MOD_RST_CTL_ADC 3
#define SUN8I_MOD_RST_CTL_DAC 2
#define SUN8I_SYS_SR_CTRL 0x018
#define SUN8I_SYS_SR_CTRL_AIF1_FS 12
@@ -54,9 +56,25 @@
#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ 4
#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16 (1 << 4)
#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT 2
+#define SUN8I_AIF1_ADCDAT_CTRL 0x044
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA 15
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA 14
#define SUN8I_AIF1_DACDAT_CTRL 0x048
#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA 15
#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA 14
+#define SUN8I_AIF1_MXR_SRC 0x04c
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L 15
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL 14
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL 13
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR 12
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R 11
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR 10
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR 9
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL 8
+#define SUN8I_ADC_DIG_CTRL 0x100
+#define SUN8I_ADC_DIG_CTRL_ENDA 15
+#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS 2
+#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY 1
#define SUN8I_DAC_DIG_CTRL 0x120
#define SUN8I_DAC_DIG_CTRL_ENDA 15
#define SUN8I_DAC_MXR_SRC 0x130
@@ -276,10 +294,28 @@ static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
};
+static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
+ SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
+ SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
+ SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
+ SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
+ SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
+};
+
static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
- /* Digital parts of the DACs */
+ /* Digital parts of the DACs and ADC */
SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("ADC", SUN8I_ADC_DIG_CTRL, SUN8I_ADC_DIG_CTRL_ENDA,
+ 0, NULL, 0),
/* Analog DAC AIF */
SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left", "Playback", 0,
@@ -289,17 +325,31 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
SUN8I_AIF1_DACDAT_CTRL,
SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
- /* DAC Mixers */
+ /* Analog ADC AIF */
+ SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left ADC", "Capture", 0,
+ SUN8I_AIF1_ADCDAT_CTRL,
+ SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA, 0),
+ SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Right ADC", "Capture", 0,
+ SUN8I_AIF1_ADCDAT_CTRL,
+ SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA, 0),
+
+ /* DAC and ADC Mixers */
SOC_MIXER_ARRAY("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
sun8i_dac_mixer_controls),
SOC_MIXER_ARRAY("Right Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
sun8i_dac_mixer_controls),
+ SOC_MIXER_ARRAY("Left Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
+ sun8i_input_mixer_controls),
+ SOC_MIXER_ARRAY("Right Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
+ sun8i_input_mixer_controls),
/* Clocks */
SND_SOC_DAPM_SUPPLY("MODCLK AFI1", SUN8I_MOD_CLK_ENA,
SUN8I_MOD_CLK_ENA_AIF1, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("MODCLK DAC", SUN8I_MOD_CLK_ENA,
SUN8I_MOD_CLK_ENA_DAC, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MODCLK ADC", SUN8I_MOD_CLK_ENA,
+ SUN8I_MOD_CLK_ENA_ADC, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("AIF1", SUN8I_SYSCLK_CTL,
SUN8I_SYSCLK_CTL_AIF1CLK_ENA, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("SYSCLK", SUN8I_SYSCLK_CTL,
@@ -316,6 +366,12 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
SUN8I_MOD_RST_CTL_AIF1, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("RST DAC", SUN8I_MOD_RST_CTL,
SUN8I_MOD_RST_CTL_DAC, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("RST ADC", SUN8I_MOD_RST_CTL,
+ SUN8I_MOD_RST_CTL_ADC, 0, NULL, 0),
+
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("Mic", NULL),
+
};
static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
@@ -325,11 +381,16 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
{ "RST AIF1", NULL, "AIF1 PLL" },
{ "MODCLK AFI1", NULL, "RST AIF1" },
{ "DAC", NULL, "MODCLK AFI1" },
+ { "ADC", NULL, "MODCLK AFI1" },
{ "RST DAC", NULL, "SYSCLK" },
{ "MODCLK DAC", NULL, "RST DAC" },
{ "DAC", NULL, "MODCLK DAC" },
+ { "RST ADC", NULL, "SYSCLK" },
+ { "MODCLK ADC", NULL, "RST ADC" },
+ { "ADC", NULL, "MODCLK ADC" },
+
/* DAC Routes */
{ "AIF1 Slot 0 Right", NULL, "DAC" },
{ "AIF1 Slot 0 Left", NULL, "DAC" },
@@ -339,6 +400,12 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
"AIF1 Slot 0 Left"},
{ "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
"AIF1 Slot 0 Right"},
+
+ /* ADC routes */
+ { "Left Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
+ "AIF1 Slot 0 Left ADC" },
+ { "Right Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
+ "AIF1 Slot 0 Right ADC" },
};
static struct snd_soc_dai_ops sun8i_codec_dai_ops = {
@@ -356,6 +423,15 @@ static struct snd_soc_dai_driver sun8i_codec_dai = {
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
+ /* capture capabilities */
+ .capture = {
+ .stream_name = "Capture",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_8000_192000,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .sig_bits = 24,
+ },
/* pcm operations */
.ops = &sun8i_codec_dai_ops,
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/2] ASoC: sunxi: Add ADC support for A33
From: Mylène Josserand @ 2017-05-03 13:56 UTC (permalink / raw)
To: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Hello everyone,
This is a first version of a serie to add ADC support
for Sun8i-A33.
Based on asoc/for-next branch, last commit:
20d5c84bef067b7e804a163e2abca16c47125bad.
The first patch adds the support of ADC and microphones in the digital
part (driver sun8i-codec).
The second one adds the route between analog (sun8i-codec-analog) and
digital (sun8i-codec) parts to have a functional ADC route on Sun8i-A33
device tree.
Tested on Allwinner R16 Parrot board with microphone 1 (external) and
microphone 2 (headset).
I am not sure about the bias handling so if you have any comments on it,
do not hesitate.
Thank you in advance!
Best regards,
Mylène Josserand (2):
ASoC: sun8i-codec: Add ADC support for a33
ARM: dts: sun8i: Add ADC routing
arch/arm/boot/dts/sun8i-a33.dtsi | 10 ++++-
sound/soc/sunxi/sun8i-codec.c | 80 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 87 insertions(+), 3 deletions(-)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 7/7] ARM: ZTE: Use - instead of @ for DT OPP entries
From: Shawn Guo @ 2017-05-03 13:42 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, Mark Rutland, Rob Herring,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Rafael Wysocki,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Krzysztof Kozlowski,
Masahiro Yamada, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <5534c08d8b452c8ce623d3e465603d94afd82ed4.1492685450.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Apr 20, 2017 at 04:25:11PM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reported-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Suggested-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Changed the subject prefix to 'arm64: dts: zte: ', and applied the
patch.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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