* Re: [PATCH 2/2] iio:imu:mpu6050 add explicit mpu9250 support
From: Rob Herring @ 2017-03-30 23:18 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark.Rutland-5wv7dgnIgG8
In-Reply-To: <20170326111100.2571-3-jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Sun, Mar 26, 2017 at 12:11:00PM +0100, Jonathan Cameron wrote:
> The mpu9250 is a SIP containing an mpu6500 and an ak8975. If this was all
> there was too it there would be no need for explicit handling in the driver.
> Arguably the bindings would also only reflect the presence of an mpu6500 with
> the ak8975 hanging off it, as the kernel doesn't care that they are in one
> package.
>
> However, the WHOAMI value changes as well so best to add explicit support.
>
> Signed-off-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt | 2 +-
> drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 6 ++++++
> drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 5 +++++
> drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 2 ++
> drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c | 1 +
> 5 files changed, 15 insertions(+), 1 deletion(-)
Same one per line comment, but
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v2 5/6] dt-bindings: List devicetree binding for the CCU of Allwinner A10
From: Rob Herring @ 2017-03-30 23:19 UTC (permalink / raw)
To: Priit Laes
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng, Russell King,
Chen-Yu Tsai, Maxime Ripard, Mark Rutland, Stephen Boyd,
Michael Turquette, Philipp Zabel
In-Reply-To: <28a3c670575f368a2bd9a67b451f0f45c474dc7b.1490545262.git-series.plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
On Sun, Mar 26, 2017 at 08:20:20PM +0300, Priit Laes wrote:
> Allwinner A10 is now driven by sunxi-ng CCU driver.
>
> Add devicetree binding for it.
>
> Signed-off-by: Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCHv3] power: supply: cpcap-charger: Add minimal CPCAP PMIC battery charger
From: Rob Herring @ 2017-03-30 23:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Sebastian Reichel, linux-pm, linux-omap, devicetree,
Marcel Partap, Michael Scott
In-Reply-To: <20170327032513.22890-1-tony@atomide.com>
On Sun, Mar 26, 2017 at 08:25:13PM -0700, Tony Lindgren wrote:
> The custom CPCAP PMIC used on Motorola phones such as Droid 4 has a
> USB battery charger. It can optionally also have a companion chip that
> is used for wireless charging.
>
> The charger on CPCAP also can feed VBUS for the USB host mode. This
> can be handled by the existing kernel phy_companion interface.
>
> Cc: devicetree@vger.kernel.org
> Cc: Marcel Partap <mpartap@gmx.net>
> Cc: Michael Scott <michael.scott@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> Changes since v2:
>
> - Update binding based on comments by Sebastian Reichel <sre@kernel.org>
>
> - Drop "motorola,cpcap-charger" compatible for now as this seems specific
> to the motorola-mapphone
>
> - Update Kconfig for "depends on IIO" and "default MFD_CPCAP"
>
> Changes since v1:
>
> - Fix scaling of IIO values as pointed out by Sebastian Reichel
> <sre@kernel.org>
>
> - Use iio_read_channel_processed() instead of iio_read_channel_scaled()
> as changed in the v2 of the ADC driver
>
> - Add GPL v2 license header
>
> ---
> .../bindings/power/supply/cpcap-charger.txt | 38 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/power/supply/Kconfig | 8 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/cpcap-charger.c | 681 +++++++++++++++++++++
> 4 files changed, 728 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/cpcap-charger.txt
> create mode 100644 drivers/power/supply/cpcap-charger.c
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: mtd: document linux,part-probe property
From: Marek Vasut @ 2017-03-30 23:26 UTC (permalink / raw)
To: Rafał Miłecki, David Woodhouse, Brian Norris,
Boris Brezillon, Richard Weinberger, Cyrille Pitchen
Cc: Mark Rutland, devicetree, Linus Walleij, Rob Herring, linux-mtd,
Rafał Miłecki, Frank Rowand
In-Reply-To: <20170330215332.32699-2-zajec5@gmail.com>
On 03/30/2017 11:53 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Support for this property has been introduced in 2010 with commit
> 9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
> parition probe") but it was never documented. Fix this by adding a
> proper description and example.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
> index fc068b923d7a..1ada70e718b2 100644
> --- a/Documentation/devicetree/bindings/mtd/common.txt
> +++ b/Documentation/devicetree/bindings/mtd/common.txt
> @@ -6,10 +6,17 @@ Optional properties:
> controller based name) in order to ease flash device identification
> and/or describe what they are used for.
>
> +- linux,part-probe: if present, this property should contain a list of strings
> + with partition probes to be used for the flash device. A role of partition
> + probe (parser) is to read/construct partition table and register found
> + partitions. Getting partition table may be platform or device specific so
> + various devices may use various Linux drivers for this purpose.
Why don't you just have partition not within partition node ? Then you
won't need this nonsense ...
> Example:
>
> flash@0 {
> label = "System-firmware";
> + linux,part-probe = "cmdlinepart", "ofpart";
>
> /* flash type specific properties */
> };
>
--
Best regards,
Marek Vasut
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v6 0/5] i2c: aspeed: added driver for Aspeed I2C
From: Andrew Jeffery @ 2017-03-31 0:01 UTC (permalink / raw)
To: Brendan Higgins, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, jason-NLaQJdtUoK4Be96aLqz0jA,
marc.zyngier-5wv7dgnIgG8, joel-U3u1mxZcP9KHXe+LvDLADg,
vz-ChpfBGZJDbMAvxtiuMwx3w, mouse-Pma6HLj0uuo, clg-Bxea+6Xhats
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170328051226.21677-1-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]
On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote:
> Sorry for the delay, I went on a long vacation prior to receiving feedback and
> got back in the middle of a hardware bring up that consumed all of my attention
> for an extended period of time. I will try to plan upstream submissions around
> my other responsibilities better in the future.
>
> Addressed comments from:
> - Vladimir in: https://www.spinics.net/lists/linux-i2c/msg27387.html
> and: https://www.spinics.net/lists/linux-i2c/msg27386.html
> - Wolfram in: https://www.spinics.net/lists/linux-i2c/msg27476.html
> and: https://www.spinics.net/lists/linux-i2c/msg27483.html
>
> Changes since previous update:
> - No longer arbitrarily restrict bus to be slave xor master.
> - Pulled out "struct aspeed_i2c_controller" as a interrupt controller.
> - Pulled out slave support into its own commit.
> - Rewrote code that sets clock divider register because the original version
> set it incorrectly.
> - Discovered and fixed issue in implementation that caused certain slave
> devices to misbehave; the cause was that the master IRQ handler would return
> control to the requesting thread after the last RX or TX command was handled
> such that the requesting thread would issue either a repeated start or stop.
> This was incorrect because the time taken to complete the completion was too
> great. I fixed this by rewriting the master IRQ handler so that it now
> manages the entire transaction only returning control to the requesting
> thread once the entire transaction is complete.
> - Rewrote the aspeed_i2c_master_irq handler because the old method of
> completing a completion in between restarts was too slow causing devices to
> misbehave.
> - Added support for I2C_M_RECV_LEN which I had incorrectly said was supported
> before.
> - Addressed other comments from Vladimir.
>
> Changes have been tested on the Aspeed 2500 evaluation board, as before, and now
> on a real platform with an Aspeed 2520.
Looks like there's going to be another revision of the series, but
regardless, I've applied and tested v6 and had no issues. So:
Tested-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C
From: Joel Stanley @ 2017-03-31 0:33 UTC (permalink / raw)
To: Brendan Higgins
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, vz, mouse, Cédric Le Goater,
linux-i2c, devicetree, Linux Kernel Mailing List,
OpenBMC Maillist, Benjamin Herrenschmidt
In-Reply-To: <20170328051226.21677-5-brendanhiggins@google.com>
On Tue, Mar 28, 2017 at 3:42 PM, Brendan Higgins
<brendanhiggins@google.com> wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
Mention that the driver supports byte at a time access only at this stage.
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Looking good. I've given this a spin on ast2500 hardware and it worked for me.
I've got a bunch of nits below, and one bigger question about weather
we need internal locking in the driver, or if we can rely on the i2c
core for our locks.
> ---
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-aspeed.c | 610 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 621 insertions(+)
> create mode 100644 drivers/i2c/busses/i2c-aspeed.c
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 8adc0f1d7ad0..e5ea5641a874 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -326,6 +326,16 @@ config I2C_POWERMAC
>
> comment "I2C system bus drivers (mostly embedded / system-on-chip)"
>
> +config I2C_ASPEED
> + tristate "Aspeed AST2xxx SoC I2C Controller"
Aspeed I2C Controller
> + depends on ARCH_ASPEED
> + help
> + If you say yes to this option, support will be included for the
> + Aspeed AST2xxx SoC I2C controller.
And again.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-aspeed.
> +
> config I2C_AT91
> tristate "Atmel AT91 I2C Two-Wire interface (TWI)"
> depends on ARCH_AT91
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> new file mode 100644
> index 000000000000..04266acc6c46
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> + spin_unlock_irqrestore(&bus->lock, flags);
> +
> + return ret;
> +}
> +
> +static void do_start(struct aspeed_i2c_bus *bus)
aspeed_i2c_do_start
> +{
> + u32 command = ASPEED_I2CD_M_START_CMD | ASPEED_I2CD_M_TX_CMD;
> + struct i2c_msg *msg = &bus->msgs[bus->msgs_index];
> + u8 slave_addr = msg->addr << 1;
> +
> + bus->master_state = ASPEED_I2C_MASTER_START;
> + bus->buf_index = 0;
> +
> + if (msg->flags & I2C_M_RD) {
> + slave_addr |= 1;
> + command |= ASPEED_I2CD_M_RX_CMD;
> + /* Need to let the hardware know to NACK after RX. */
> + if (msg->len == 1 && !(msg->flags & I2C_M_RECV_LEN))
> + command |= ASPEED_I2CD_M_S_RX_CMD_LAST;
> + }
> +
> + aspeed_i2c_write(bus, slave_addr, ASPEED_I2C_BYTE_BUF_REG);
> + aspeed_i2c_write(bus, command, ASPEED_I2C_CMD_REG);
> +}
> +
> +static void do_stop(struct aspeed_i2c_bus *bus)
aspeed_i2c_do_stop
> +{
> + bus->master_state = ASPEED_I2C_MASTER_STOP;
> + aspeed_i2c_write(bus, ASPEED_I2CD_M_STOP_CMD,
> + ASPEED_I2C_CMD_REG);
> +}
> +static int aspeed_i2c_probe_bus(struct platform_device *pdev)
> +{
> + struct aspeed_i2c_bus *bus;
> + struct resource *res;
> + int ret;
> +
> + bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> + if (!bus)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + bus->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(bus->base)) {
> + dev_err(&pdev->dev, "failed to devm_ioremap_resource\n");
devm_ioremap_resource shows an error for you, please drop the dev_err here.
> + return PTR_ERR(bus->base);
> + }
> +
> + bus->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + ret = devm_request_irq(&pdev->dev, bus->irq, aspeed_i2c_bus_irq,
> + IRQF_SHARED, dev_name(&pdev->dev), bus);
Is this requesting an IRQ from your i2c-irq-controller? In which case
the IRQ won't be shared with any other driver, so you don't need to
set IRQF_SHARED.
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to request interrupt\n");
> + return ret;
> + }
> +
> + /* Initialize the I2C adapter */
> + spin_lock_init(&bus->lock);
Do we need this lock at all?
The i2c core provides locking around operations on the bus. I was
browsing some of the other bus drivers and they do not have locking
inside of the driver (eg. i2c-at91.c). I also did a test of an earlier
version of this driver where I removed the locks, and it performed
correctly in my testing (http://patchwork.ozlabs.org/patch/731899/).
> + init_completion(&bus->cmd_complete);
> + bus->adap.owner = THIS_MODULE;
> + bus->adap.retries = 0;
> + bus->adap.timeout = 5 * HZ;
> + bus->adap.algo = &aspeed_i2c_algo;
> + bus->adap.algo_data = bus;
> + bus->adap.dev.parent = &pdev->dev;
> + bus->adap.dev.of_node = pdev->dev.of_node;
> + snprintf(bus->adap.name, sizeof(bus->adap.name), "Aspeed i2c");
> +static struct platform_driver aspeed_i2c_bus_driver = {
> + .probe = aspeed_i2c_probe_bus,
> + .remove = aspeed_i2c_remove_bus,
> + .driver = {
> + .name = "ast-i2c-bus",
aspeed-i2c-bus please.
> + .of_match_table = aspeed_i2c_bus_of_table,
> + },
> +};
> +module_platform_driver(aspeed_i2c_bus_driver);
> +
> +MODULE_AUTHOR("Brendan Higgins <brendanhiggins@google.com>");
> +MODULE_DESCRIPTION("Aspeed I2C Bus Driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.12.2.564.g063fe858b8-goog
>
^ permalink raw reply
* Re: [PATCH v5 6/9] coresight: add support for CPU debug module
From: Leo Yan @ 2017-03-31 0:54 UTC (permalink / raw)
To: Sudeep Holla
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Michael Turquette, Stephen Boyd, Mathieu Poirier, Guodong Xu,
John Stultz, linux-doc, linux-kernel, devicetree,
linux-arm-kernel, linux-arm-msm, linux-soc, linux-clk, mike.leach,
Suzuki.Poulose
In-Reply-To: <f0c460e2-4e49-4f34-5288-f20a519dc182@arm.com>
On Thu, Mar 30, 2017 at 04:56:52PM +0100, Sudeep Holla wrote:
[...]
> > +static struct pm_qos_request debug_qos_req;
> > +static int idle_constraint = PM_QOS_DEFAULT_VALUE;
> > +module_param(idle_constraint, int, 0600);
> > +MODULE_PARM_DESC(idle_constraint, "Latency requirement in microseconds for CPU "
> > + "idle states (default is -1, which means have no limiation "
> > + "to CPU idle states; 0 means disabling all idle states; user "
> > + "can choose other platform dependent values so can disable "
> > + "specific idle states for the platform)");
> > +
>
> NACK for this. Why you want the policy inside the driver. You can always
> do that from the user-space. I have mentioned it several times now.
> What can't you do these ?
>
> 1. echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency
> 2. echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> (for all cpus and their states) (1) is definitely simpler way to
> disable deeper idle if latency = 0uS
>
> You can always warn user about that when it's enabled via debugfs/sysfs
Thanks for suggestion, now it's clear for me.
> --
> Regards,
> Sudeep
^ permalink raw reply
* Re: [PATCH V11 6/6] thermal: bcm2835: add thermal driver for bcm2835 SoC
From: Eduardo Valentin @ 2017-03-31 1:06 UTC (permalink / raw)
To: Stefan Wahren
Cc: Frank Rowand, kernel-TqfNSX0MhmxHKSADF0wUEw, Eric Anholt,
Zhang Rui, Rob Herring, Florian Fainelli,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1620097357.332334.1490901102005-7tX72C7vayboQLBSYMtkGA@public.gmane.org>
Hello,
On Thu, Mar 30, 2017 at 09:11:41PM +0200, Stefan Wahren wrote:
> Hi Eduardo,
>
> > Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> hat am 30. März 2017 um 06:57 geschrieben:
> >
> >
<cut>
> > A third option on top of what I suggested above is to split the series.
> > Given that you could still get the proper coefficients
> > with current of-thermal, I would suggest you to split this series into
> > two (patches 1-2, 3-6) in your next version, so we avoid futher delays
> > on the driver, while patches 1-2 waits for acks from OF side.
>
> i revert patches #1, #2 and the slope value was still correct. So i will choose the third option and split the series.
Sounds good to me.
>
> Thanks
> Stefan
>
> >
> > [1] - https://patchwork.kernel.org/patch/9612613/
--
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 V11 6/6] thermal: bcm2835: add thermal driver for bcm2835 SoC
From: Eduardo Valentin @ 2017-03-31 1:08 UTC (permalink / raw)
To: Stefan Wahren
Cc: Frank Rowand, kernel-TqfNSX0MhmxHKSADF0wUEw, Eric Anholt,
Zhang Rui, Rob Herring, Florian Fainelli,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1205844664.21224.1490855429497-7tX72C7vayboQLBSYMtkGA@public.gmane.org>
Hello,
On Thu, Mar 30, 2017 at 08:30:29AM +0200, Stefan Wahren wrote:
>
> > Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> hat am 30. März 2017 um 06:57 geschrieben:
> >
> >
> > On Tue, Mar 28, 2017 at 09:58:09PM -0700, Eduardo Valentin wrote:
> > > On Sun, Mar 12, 2017 at 10:11:05PM +0000, Stefan Wahren wrote:
> > > > Add basic thermal driver for bcm2835 SoC.
> > > >
> > > > This driver currently make sure that tsense HW block is set up
> > > > correctly.
> > > >
> > > > Signed-off-by: Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
> > > > Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> > > > Acked-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> > >
> > > I see no issue with this driver at this point.
> > >
> > > As I mentioned, the full series needs to go together. You either get an
> > > Ack from OF maintainers, and I take the series, or you can add my
> > >
> > > Acked-by: Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >
> > > after fixing the small comment from Nobuhiro.
> > >
> >
> > Based on other drivers that require negative values, I assume patches 1
> > and 2 of these series are needed, but more for enforcing the API, given
> > that the current of-thermal driver still retrieves the negative values
> > from DTB [1].
> >
> > [1] - https://patchwork.kernel.org/patch/9612613/
>
> I can't see that the OMAP5 thermal driver is using thermal_zone_get_slope() [2]. I got the wrong values without patch 1 and 2. So i wouldn't rely on that statement. But i will doublecheck it.
The TI-SoC driver is not currently using the slope and offset from DT.
But on my -linus branch I have added three patches from Keerthy that
adds that support.
Anyways, I am assuming you are also getting correct values at your end,
based on your other email.
BR,
>
> [2] - http://elixir.free-electrons.com/ident?v=4.11-rc4&i=thermal_zone_get_slope
--
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 v4] ASoC: Add support for Maxim Integrated MAX98927 Amplifier
From: Ryan Lee @ 2017-03-31 1:16 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, mark.rutland, perex, tiwai,
kuninori.morimoto.gx, arnd, ckeepax, lars, bardliao, nh6z, KCHSU0,
axel.lin, romain.perier, srinivas.kandagatla, oder_chiou,
Paul.Handrigan, ryans.lee, alsa-devel, devicetree, linux-kernel
Cc: dgreid, ryan.lee.maxim
Signed-off-by: Ryan Lee <ryans.lee@maximintegrated.com>
---
Changes since v4:
* Removed support for SND_SOC_DAIFMT_CBS_CFM.
* Fixed coding style for indention.
* Removed variables if it has only one user.
* Assigned ch_size directly.
* Removed oring.
* Put the return false in the switch statement.
* Removed 'Monomix Output' and 'Speaker Source' controls.
* Modified control names per control-names.rst.
* Moved Revision ID check code to i2c_probe function.
* Added 'Current Limit' control.
* Removed 'devm__kfree' function.
Changes since v3:
* Combined MAX98926 and MAX98927 binding. Kept existing property name.
Changes since v2:
* Removed local register read/write function to avoid duplication of ASoC core function.
.../devicetree/bindings/sound/max98925.txt | 22 -
.../devicetree/bindings/sound/max98926.txt | 32 -
.../devicetree/bindings/sound/max9892x.txt | 41 +
sound/soc/codecs/Kconfig | 5 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/max98927.c | 841 +++++++++++++++++++++
sound/soc/codecs/max98927.h | 272 +++++++
7 files changed, 1161 insertions(+), 54 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/max98925.txt
delete mode 100644 Documentation/devicetree/bindings/sound/max98926.txt
create mode 100755 Documentation/devicetree/bindings/sound/max9892x.txt
mode change 100644 => 100755 sound/soc/codecs/Kconfig
mode change 100644 => 100755 sound/soc/codecs/Makefile
create mode 100755 sound/soc/codecs/max98927.c
create mode 100755 sound/soc/codecs/max98927.h
diff --git a/Documentation/devicetree/bindings/sound/max98925.txt b/Documentation/devicetree/bindings/sound/max98925.txt
deleted file mode 100644
index 27be63e..0000000
--- a/Documentation/devicetree/bindings/sound/max98925.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-max98925 audio CODEC
-
-This device supports I2C.
-
-Required properties:
-
- - compatible : "maxim,max98925"
-
- - vmon-slot-no : slot number used to send voltage information
-
- - imon-slot-no : slot number used to send current information
-
- - reg : the I2C address of the device for I2C
-
-Example:
-
-codec: max98925@1a {
- compatible = "maxim,max98925";
- vmon-slot-no = <0>;
- imon-slot-no = <2>;
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/max98926.txt b/Documentation/devicetree/bindings/sound/max98926.txt
deleted file mode 100644
index 0b7f4e4..0000000
--- a/Documentation/devicetree/bindings/sound/max98926.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-max98926 audio CODEC
-
-This device supports I2C.
-
-Required properties:
-
- - compatible : "maxim,max98926"
-
- - vmon-slot-no : slot number used to send voltage information
- or in inteleave mode this will be used as
- interleave slot.
-
- - imon-slot-no : slot number used to send current information
-
- - interleave-mode : When using two MAX98926 in a system it is
- possible to create ADC data that that will
- overflow the frame size. Digital Audio Interleave
- mode provides a means to output VMON and IMON data
- from two devices on a single DOUT line when running
- smaller frames sizes such as 32 BCLKS per LRCLK or
- 48 BCLKS per LRCLK.
-
- - reg : the I2C address of the device for I2C
-
-Example:
-
-codec: max98926@1a {
- compatible = "maxim,max98926";
- vmon-slot-no = <0>;
- imon-slot-no = <2>;
- reg = <0x1a>;
-};
diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt b/Documentation/devicetree/bindings/sound/max9892x.txt
new file mode 100755
index 0000000..f617159
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max9892x.txt
@@ -0,0 +1,41 @@
+Maxim Integrated MAX98925/MAX98926/MAX98927 Speaker Amplifier
+
+This device supports I2C.
+
+Required properties:
+
+ - compatible : should be one of the following
+ - "maxim,max98925"
+ - "maxim,max98926"
+ - "maxim,max98927"
+
+ - vmon-slot-no : slot number used to send voltage information
+ or in inteleave mode this will be used as
+ interleave slot.
+ MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
+ MAX98927 slot range : 0 ~ 15, Default : 0
+
+ - imon-slot-no : slot number used to send current information
+ MAX98925/MAX98926 slot range : 0 ~ 30, Default : 0
+ MAX98927 slot range : 0 ~ 15, Default : 0
+
+ - interleave-mode : When using two MAX9892X in a system it is
+ possible to create ADC data that that will
+ overflow the frame size. Digital Audio Interleave
+ mode provides a means to output VMON and IMON data
+ from two devices on a single DOUT line when running
+ smaller frames sizes such as 32 BCLKS per LRCLK or
+ 48 BCLKS per LRCLK.
+ Range : 0 (off), 1 (on), Default : 0
+
+ - reg : the I2C address of the device for I2C
+
+Example:
+
+codec: max98927@3a {
+ compatible = "maxim,max98927";
+ vmon-slot-no = <0>;
+ imon-slot-no = <1>;
+ interleave-mode = <0>;
+ reg = <0x3a>;
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
old mode 100644
new mode 100755
index e49e9da..cbdc8aa
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -89,6 +89,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MAX9867 if I2C
select SND_SOC_MAX98925 if I2C
select SND_SOC_MAX98926 if I2C
+ select SND_SOC_MAX98927 if I2C
select SND_SOC_MAX9850 if I2C
select SND_SOC_MAX9860 if I2C
select SND_SOC_MAX9768 if I2C
@@ -588,6 +589,10 @@ config SND_SOC_MAX98925
config SND_SOC_MAX98926
tristate
+config SND_SOC_MAX98927
+ tristate "Maxim Integrated MAX98927 Speaker Amplifier"
+ depends on I2C
+
config SND_SOC_MAX9850
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
old mode 100644
new mode 100755
index 1796cb9..187a639
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -84,6 +84,7 @@ snd-soc-max98371-objs := max98371.o
snd-soc-max9867-objs := max9867.o
snd-soc-max98925-objs := max98925.o
snd-soc-max98926-objs := max98926.o
+snd-soc-max98927-objs := max98927.o
snd-soc-max9850-objs := max9850.o
snd-soc-max9860-objs := max9860.o
snd-soc-mc13783-objs := mc13783.o
@@ -313,6 +314,7 @@ obj-$(CONFIG_SND_SOC_MAX98357A) += snd-soc-max98357a.o
obj-$(CONFIG_SND_SOC_MAX9867) += snd-soc-max9867.o
obj-$(CONFIG_SND_SOC_MAX98925) += snd-soc-max98925.o
obj-$(CONFIG_SND_SOC_MAX98926) += snd-soc-max98926.o
+obj-$(CONFIG_SND_SOC_MAX98927) += snd-soc-max98927.o
obj-$(CONFIG_SND_SOC_MAX9850) += snd-soc-max9850.o
obj-$(CONFIG_SND_SOC_MAX9860) += snd-soc-max9860.o
obj-$(CONFIG_SND_SOC_MC13783) += snd-soc-mc13783.o
diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
new file mode 100755
index 0000000..b5ee294
--- /dev/null
+++ b/sound/soc/codecs/max98927.c
@@ -0,0 +1,841 @@
+/*
+ * max98927.c -- MAX98927 ALSA Soc Audio driver
+ *
+ * Copyright (C) 2016 Maxim Integrated Products
+ * Author: Ryan Lee <ryans.lee@maximintegrated.com>
+ *
+ * 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.
+ */
+
+#include <linux/acpi.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/cdev.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <sound/tlv.h>
+#include "max98927.h"
+
+static struct reg_default max98927_reg[] = {
+ {MAX98927_R0001_INT_RAW1, 0x00},
+ {MAX98927_R0002_INT_RAW2, 0x00},
+ {MAX98927_R0003_INT_RAW3, 0x00},
+ {MAX98927_R0004_INT_STATE1, 0x00},
+ {MAX98927_R0005_INT_STATE2, 0x00},
+ {MAX98927_R0006_INT_STATE3, 0x00},
+ {MAX98927_R0007_INT_FLAG1, 0x00},
+ {MAX98927_R0008_INT_FLAG2, 0x00},
+ {MAX98927_R0009_INT_FLAG3, 0x00},
+ {MAX98927_R000A_INT_EN1, 0x00},
+ {MAX98927_R000B_INT_EN2, 0x00},
+ {MAX98927_R000C_INT_EN3, 0x00},
+ {MAX98927_R000D_INT_FLAG_CLR1, 0x00},
+ {MAX98927_R000E_INT_FLAG_CLR2, 0x00},
+ {MAX98927_R000F_INT_FLAG_CLR3, 0x00},
+ {MAX98927_R0010_IRQ_CTRL, 0x00},
+ {MAX98927_R0011_CLK_MON, 0x00},
+ {MAX98927_R0012_WDOG_CTRL, 0x00},
+ {MAX98927_R0013_WDOG_RST, 0x00},
+ {MAX98927_R0014_MEAS_ADC_THERM_WARN_THRESH, 0x00},
+ {MAX98927_R0015_MEAS_ADC_THERM_SHDN_THRESH, 0x00},
+ {MAX98927_R0016_MEAS_ADC_THERM_HYSTERESIS, 0x00},
+ {MAX98927_R0017_PIN_CFG, 0x55},
+ {MAX98927_R0018_PCM_RX_EN_A, 0x00},
+ {MAX98927_R0019_PCM_RX_EN_B, 0x00},
+ {MAX98927_R001A_PCM_TX_EN_A, 0x00},
+ {MAX98927_R001B_PCM_TX_EN_B, 0x00},
+ {MAX98927_R001C_PCM_TX_HIZ_CTRL_A, 0x00},
+ {MAX98927_R001D_PCM_TX_HIZ_CTRL_B, 0x00},
+ {MAX98927_R001E_PCM_TX_CH_SRC_A, 0x00},
+ {MAX98927_R001F_PCM_TX_CH_SRC_B, 0x00},
+ {MAX98927_R0020_PCM_MODE_CFG, 0x40},
+ {MAX98927_R0021_PCM_MASTER_MODE, 0x00},
+ {MAX98927_R0022_PCM_CLK_SETUP, 0x22},
+ {MAX98927_R0023_PCM_SR_SETUP1, 0x00},
+ {MAX98927_R0024_PCM_SR_SETUP2, 0x00},
+ {MAX98927_R0025_PCM_TO_SPK_MONOMIX_A, 0x00},
+ {MAX98927_R0026_PCM_TO_SPK_MONOMIX_B, 0x00},
+ {MAX98927_R0027_ICC_RX_EN_A, 0x00},
+ {MAX98927_R0028_ICC_RX_EN_B, 0x00},
+ {MAX98927_R002B_ICC_TX_EN_A, 0x00},
+ {MAX98927_R002C_ICC_TX_EN_B, 0x00},
+ {MAX98927_R002E_ICC_HIZ_MANUAL_MODE, 0x00},
+ {MAX98927_R002F_ICC_TX_HIZ_EN_A, 0x00},
+ {MAX98927_R0030_ICC_TX_HIZ_EN_B, 0x00},
+ {MAX98927_R0031_ICC_LNK_EN, 0x00},
+ {MAX98927_R0032_PDM_TX_EN, 0x00},
+ {MAX98927_R0033_PDM_TX_HIZ_CTRL, 0x00},
+ {MAX98927_R0034_PDM_TX_CTRL, 0x00},
+ {MAX98927_R0035_PDM_RX_CTRL, 0x00},
+ {MAX98927_R0036_AMP_VOL_CTRL, 0x00},
+ {MAX98927_R0037_AMP_DSP_CFG, 0x02},
+ {MAX98927_R0038_TONE_GEN_DC_CFG, 0x00},
+ {MAX98927_R0039_DRE_CTRL, 0x01},
+ {MAX98927_R003A_AMP_EN, 0x00},
+ {MAX98927_R003B_SPK_SRC_SEL, 0x00},
+ {MAX98927_R003C_SPK_GAIN, 0x00},
+ {MAX98927_R003D_SSM_CFG, 0x01},
+ {MAX98927_R003E_MEAS_EN, 0x00},
+ {MAX98927_R003F_MEAS_DSP_CFG, 0x04},
+ {MAX98927_R0040_BOOST_CTRL0, 0x00},
+ {MAX98927_R0041_BOOST_CTRL3, 0x00},
+ {MAX98927_R0042_BOOST_CTRL1, 0x00},
+ {MAX98927_R0043_MEAS_ADC_CFG, 0x00},
+ {MAX98927_R0044_MEAS_ADC_BASE_MSB, 0x00},
+ {MAX98927_R0045_MEAS_ADC_BASE_LSB, 0x00},
+ {MAX98927_R0046_ADC_CH0_DIVIDE, 0x00},
+ {MAX98927_R0047_ADC_CH1_DIVIDE, 0x00},
+ {MAX98927_R0048_ADC_CH2_DIVIDE, 0x00},
+ {MAX98927_R0049_ADC_CH0_FILT_CFG, 0x00},
+ {MAX98927_R004A_ADC_CH1_FILT_CFG, 0x00},
+ {MAX98927_R004B_ADC_CH2_FILT_CFG, 0x00},
+ {MAX98927_R004C_MEAS_ADC_CH0_READ, 0x00},
+ {MAX98927_R004D_MEAS_ADC_CH1_READ, 0x00},
+ {MAX98927_R004E_MEAS_ADC_CH2_READ, 0x00},
+ {MAX98927_R0051_BROWNOUT_STATUS, 0x00},
+ {MAX98927_R0052_BROWNOUT_EN, 0x00},
+ {MAX98927_R0053_BROWNOUT_INFINITE_HOLD, 0x00},
+ {MAX98927_R0054_BROWNOUT_INFINITE_HOLD_CLR, 0x00},
+ {MAX98927_R0055_BROWNOUT_LVL_HOLD, 0x00},
+ {MAX98927_R005A_BROWNOUT_LVL1_THRESH, 0x00},
+ {MAX98927_R005B_BROWNOUT_LVL2_THRESH, 0x00},
+ {MAX98927_R005C_BROWNOUT_LVL3_THRESH, 0x00},
+ {MAX98927_R005D_BROWNOUT_LVL4_THRESH, 0x00},
+ {MAX98927_R005E_BROWNOUT_THRESH_HYSTERYSIS, 0x00},
+ {MAX98927_R005F_BROWNOUT_AMP_LIMITER_ATK_REL, 0x00},
+ {MAX98927_R0060_BROWNOUT_AMP_GAIN_ATK_REL, 0x00},
+ {MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE, 0x00},
+ {MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT, 0x00},
+ {MAX98927_R0073_BROWNOUT_LVL1_AMP1_CTRL1, 0x00},
+ {MAX98927_R0074_BROWNOUT_LVL1_AMP1_CTRL2, 0x00},
+ {MAX98927_R0075_BROWNOUT_LVL1_AMP1_CTRL3, 0x00},
+ {MAX98927_R0076_BROWNOUT_LVL2_CUR_LIMIT, 0x00},
+ {MAX98927_R0077_BROWNOUT_LVL2_AMP1_CTRL1, 0x00},
+ {MAX98927_R0078_BROWNOUT_LVL2_AMP1_CTRL2, 0x00},
+ {MAX98927_R0079_BROWNOUT_LVL2_AMP1_CTRL3, 0x00},
+ {MAX98927_R007A_BROWNOUT_LVL3_CUR_LIMIT, 0x00},
+ {MAX98927_R007B_BROWNOUT_LVL3_AMP1_CTRL1, 0x00},
+ {MAX98927_R007C_BROWNOUT_LVL3_AMP1_CTRL2, 0x00},
+ {MAX98927_R007D_BROWNOUT_LVL3_AMP1_CTRL3, 0x00},
+ {MAX98927_R007E_BROWNOUT_LVL4_CUR_LIMIT, 0x00},
+ {MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1, 0x00},
+ {MAX98927_R0080_BROWNOUT_LVL4_AMP1_CTRL2, 0x00},
+ {MAX98927_R0081_BROWNOUT_LVL4_AMP1_CTRL3, 0x00},
+ {MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM, 0x00},
+ {MAX98927_R0083_ENV_TRACK_BOOST_VOUT_DELAY, 0x00},
+ {MAX98927_R0084_ENV_TRACK_REL_RATE, 0x00},
+ {MAX98927_R0085_ENV_TRACK_HOLD_RATE, 0x00},
+ {MAX98927_R0086_ENV_TRACK_CTRL, 0x00},
+ {MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ, 0x00},
+ {MAX98927_R00FF_GLOBAL_SHDN, 0x00},
+ {MAX98927_R0100_SOFT_RESET, 0x00},
+ {MAX98927_R01FF_REV_ID, 0x40},
+};
+
+static int max98927_dai_set_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt)
+{
+ struct snd_soc_codec *codec = codec_dai->codec;
+ struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
+ unsigned int mode = 0;
+ unsigned int format = 0;
+ unsigned int invert = 0;
+
+ dev_dbg(codec->dev, "%s: fmt 0x%08X\n", __func__, fmt);
+
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBS_CFS:
+ mode = MAX98927_PCM_MASTER_MODE_SLAVE;
+ break;
+ case SND_SOC_DAIFMT_CBM_CFM:
+ max98927->master = true;
+ mode = MAX98927_PCM_MASTER_MODE_MASTER;
+ break;
+ default:
+ dev_err(codec->dev, "DAI clock mode unsupported");
+ return -EINVAL;
+ }
+
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0021_PCM_MASTER_MODE,
+ MAX98927_PCM_MASTER_MODE_MASK,
+ mode);
+
+ switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+ case SND_SOC_DAIFMT_NB_NF:
+ break;
+ case SND_SOC_DAIFMT_IB_NF:
+ invert = MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE;
+ break;
+ default:
+ dev_err(codec->dev, "DAI invert mode unsupported");
+ return -EINVAL;
+ }
+
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0020_PCM_MODE_CFG,
+ MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE,
+ invert);
+
+ /* interface format */
+ switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_I2S:
+ max98927->iface |= SND_SOC_DAIFMT_I2S;
+ format = MAX98927_PCM_FORMAT_I2S;
+ break;
+ case SND_SOC_DAIFMT_LEFT_J:
+ max98927->iface |= SND_SOC_DAIFMT_LEFT_J;
+ format = MAX98927_PCM_FORMAT_LJ;
+ break;
+ case SND_SOC_DAIFMT_PDM:
+ max98927->iface |= SND_SOC_DAIFMT_PDM;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* pcm channel configuration */
+ if (max98927->iface & (SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_LEFT_J)) {
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0018_PCM_RX_EN_A,
+ MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN,
+ MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN);
+
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0020_PCM_MODE_CFG,
+ MAX98927_PCM_MODE_CFG_FORMAT_MASK,
+ format << MAX98927_PCM_MODE_CFG_FORMAT_SHIFT);
+
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R003B_SPK_SRC_SEL,
+ MAX98927_SPK_SRC_MASK, 0);
+
+ } else
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0018_PCM_RX_EN_A,
+ MAX98927_PCM_RX_CH0_EN | MAX98927_PCM_RX_CH1_EN, 0);
+
+ /* pdm channel configuration */
+ if (max98927->iface & SND_SOC_DAIFMT_PDM) {
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0035_PDM_RX_CTRL,
+ MAX98927_PDM_RX_EN_MASK, 1);
+
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R003B_SPK_SRC_SEL,
+ MAX98927_SPK_SRC_MASK, 3);
+ } else
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0035_PDM_RX_CTRL,
+ MAX98927_PDM_RX_EN_MASK, 0);
+ return 0;
+}
+
+/* codec MCLK rate in master mode */
+static const int rate_table[] = {
+ 5644800, 6000000, 6144000, 6500000,
+ 9600000, 11289600, 12000000, 12288000,
+ 13000000, 19200000,
+};
+
+static int max98927_set_clock(struct max98927_priv *max98927,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_codec *codec = max98927->codec;
+ /* BCLK/LRCLK ratio calculation */
+ int blr_clk_ratio = params_channels(params) * max98927->ch_size;
+ int value;
+
+ if (max98927->master) {
+ int i;
+ /* match rate to closest value */
+ for (i = 0; i < ARRAY_SIZE(rate_table); i++) {
+ if (rate_table[i] >= max98927->sysclk)
+ break;
+ }
+ if (i == ARRAY_SIZE(rate_table)) {
+ dev_err(codec->dev, "failed to find proper clock rate.\n");
+ return -EINVAL;
+ }
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0021_PCM_MASTER_MODE,
+ MAX98927_PCM_MASTER_MODE_MCLK_MASK,
+ i << MAX98927_PCM_MASTER_MODE_MCLK_RATE_SHIFT);
+ }
+
+ switch (blr_clk_ratio) {
+ case 32:
+ value = 2;
+ break;
+ case 48:
+ value = 3;
+ break;
+ case 64:
+ value = 4;
+ break;
+ default:
+ return -EINVAL;
+ }
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0022_PCM_CLK_SETUP,
+ MAX98927_PCM_CLK_SETUP_BSEL_MASK,
+ value);
+ return 0;
+}
+
+static int max98927_dai_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
+ unsigned int sampling_rate = 0;
+ unsigned int chan_sz = 0;
+
+ /* pcm mode configuration */
+ switch (snd_pcm_format_width(params_format(params))) {
+ case 16:
+ chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_16;
+ break;
+ case 24:
+ chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_24;
+ break;
+ case 32:
+ chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_32;
+ break;
+ default:
+ dev_err(codec->dev, "format unsupported %d",
+ params_format(params));
+ goto err;
+ }
+
+ max98927->ch_size = snd_pcm_format_width(params_format(params));
+
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0020_PCM_MODE_CFG,
+ MAX98927_PCM_MODE_CFG_CHANSZ_MASK, chan_sz);
+
+ dev_dbg(codec->dev, "format supported %d",
+ params_format(params));
+
+ /* sampling rate configuration */
+ switch (params_rate(params)) {
+ case 8000:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_8000;
+ break;
+ case 11025:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_11025;
+ break;
+ case 12000:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_12000;
+ break;
+ case 16000:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_16000;
+ break;
+ case 22050:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_22050;
+ break;
+ case 24000:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_24000;
+ break;
+ case 32000:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_32000;
+ break;
+ case 44100:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_44100;
+ break;
+ case 48000:
+ sampling_rate = MAX98927_PCM_SR_SET1_SR_48000;
+ break;
+ default:
+ dev_err(codec->dev, "rate %d not supported\n",
+ params_rate(params));
+ goto err;
+ }
+ /* set DAI_SR to correct LRCLK frequency */
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0023_PCM_SR_SETUP1,
+ MAX98927_PCM_SR_SET1_SR_MASK,
+ sampling_rate);
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0024_PCM_SR_SETUP2,
+ MAX98927_PCM_SR_SET2_SR_MASK,
+ sampling_rate << MAX98927_PCM_SR_SET2_SR_SHIFT);
+
+ /* set sampling rate of IV */
+ if (max98927->interleave_mode &&
+ sampling_rate > MAX98927_PCM_SR_SET1_SR_16000)
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0024_PCM_SR_SETUP2,
+ MAX98927_PCM_SR_SET2_IVADC_SR_MASK,
+ sampling_rate - 3);
+ else
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R0024_PCM_SR_SETUP2,
+ MAX98927_PCM_SR_SET2_IVADC_SR_MASK,
+ sampling_rate);
+ return max98927_set_clock(max98927, params);
+err:
+ return -EINVAL;
+}
+
+#define MAX98927_RATES SNDRV_PCM_RATE_8000_48000
+
+#define MAX98927_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE)
+
+static int max98927_dai_set_sysclk(struct snd_soc_dai *dai,
+ int clk_id, unsigned int freq, int dir)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
+
+ max98927->sysclk = freq;
+ return 0;
+}
+
+static const struct snd_soc_dai_ops max98927_dai_ops = {
+ .set_sysclk = max98927_dai_set_sysclk,
+ .set_fmt = max98927_dai_set_fmt,
+ .hw_params = max98927_dai_hw_params,
+};
+
+static int max98927_dac_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
+ struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
+
+ switch (event) {
+ case SND_SOC_DAPM_POST_PMU:
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R003A_AMP_EN,
+ MAX98927_AMP_EN_MASK, 1);
+ /* enable VMON and IMON */
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R003E_MEAS_EN,
+ MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN,
+ MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN);
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R00FF_GLOBAL_SHDN,
+ MAX98927_GLOBAL_EN_MASK, 1);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R00FF_GLOBAL_SHDN,
+ MAX98927_GLOBAL_EN_MASK, 0);
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R003A_AMP_EN,
+ MAX98927_AMP_EN_MASK, 0);
+ /* disable VMON and IMON */
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R003E_MEAS_EN,
+ MAX98927_MEAS_V_EN | MAX98927_MEAS_I_EN, 0);
+ break;
+ default:
+ return 0;
+ }
+ return 0;
+}
+
+static const char * const max98927_switch_text[] = {
+ "Left", "Right", "LeftRight"};
+
+static const struct soc_enum dai_sel_enum =
+ SOC_ENUM_SINGLE(MAX98927_R0025_PCM_TO_SPK_MONOMIX_A,
+ MAX98927_PCM_TO_SPK_MONOMIX_CFG_SHIFT,
+ 3, max98927_switch_text);
+
+static const struct snd_kcontrol_new max98927_dai_controls =
+ SOC_DAPM_ENUM("DAI Sel", dai_sel_enum);
+
+static const struct snd_soc_dapm_widget max98927_dapm_widgets[] = {
+ SND_SOC_DAPM_AIF_IN("DAI_OUT", "HiFi Playback", 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_DAC_E("Amp Enable", "HiFi Playback", MAX98927_R003A_AMP_EN,
+ 0, 0, max98927_dac_event,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
+ SND_SOC_DAPM_MUX("DAI Sel Mux", SND_SOC_NOPM, 0, 0,
+ &max98927_dai_controls),
+ SND_SOC_DAPM_OUTPUT("BE_OUT"),
+};
+
+static DECLARE_TLV_DB_SCALE(max98927_spk_tlv, 300, 300, 0);
+static DECLARE_TLV_DB_SCALE(max98927_digital_tlv, -1600, 25, 0);
+
+static bool max98927_readable_register(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case MAX98927_R0001_INT_RAW1 ... MAX98927_R0028_ICC_RX_EN_B:
+ case MAX98927_R002B_ICC_TX_EN_A ... MAX98927_R002C_ICC_TX_EN_B:
+ case MAX98927_R002E_ICC_HIZ_MANUAL_MODE
+ ... MAX98927_R004E_MEAS_ADC_CH2_READ:
+ case MAX98927_R0051_BROWNOUT_STATUS
+ ... MAX98927_R0055_BROWNOUT_LVL_HOLD:
+ case MAX98927_R005A_BROWNOUT_LVL1_THRESH
+ ... MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE:
+ case MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT
+ ... MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ:
+ case MAX98927_R00FF_GLOBAL_SHDN:
+ case MAX98927_R0100_SOFT_RESET:
+ case MAX98927_R01FF_REV_ID:
+ return true;
+ default:
+ return false;
+ }
+};
+
+static bool max98927_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case MAX98927_R0001_INT_RAW1 ... MAX98927_R0009_INT_FLAG3:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const char * const max98927_boost_voltage_text[] = {
+ "6.5V", "6.625V", "6.75V", "6.875V", "7V", "7.125V", "7.25V", "7.375V",
+ "7.5V", "7.625V", "7.75V", "7.875V", "8V", "8.125V", "8.25V", "8.375V",
+ "8.5V", "8.625V", "8.75V", "8.875V", "9V", "9.125V", "9.25V", "9.375V",
+ "9.5V", "9.625V", "9.75V", "9.875V", "10V"
+};
+
+static SOC_ENUM_SINGLE_DECL(max98927_boost_voltage,
+ MAX98927_R0040_BOOST_CTRL0, 0,
+ max98927_boost_voltage_text);
+
+static const char * const max98927_current_limit_text[] = {
+ "1.00A", "1.10A", "1.20A", "1.30A", "1.40A", "1.50A", "1.60A", "1.70A",
+ "1.80A", "1.90A", "2.00A", "2.10A", "2.20A", "2.30A", "2.40A", "2.50A",
+ "2.60A", "2.70A", "2.80A", "2.90A", "3.00A", "3.10A", "3.20A", "3.30A",
+ "3.40A", "3.50A", "3.60A", "3.70A", "3.80A", "3.90A", "4.00A", "4.10A"
+};
+
+static SOC_ENUM_SINGLE_DECL(max98927_current_limit,
+ MAX98927_R0042_BOOST_CTRL1, 1,
+ max98927_current_limit_text);
+
+static const struct snd_kcontrol_new max98927_snd_controls[] = {
+ SOC_SINGLE_TLV("Speaker Volume", MAX98927_R003C_SPK_GAIN,
+ 0, 6, 0,
+ max98927_spk_tlv),
+ SOC_SINGLE_TLV("Digital Volume", MAX98927_R0036_AMP_VOL_CTRL,
+ 0, (1<<MAX98927_AMP_VOL_WIDTH)-1, 0,
+ max98927_digital_tlv),
+ SOC_SINGLE("Amp DSP Switch", MAX98927_R0052_BROWNOUT_EN,
+ MAX98927_BROWNOUT_DSP_SHIFT, 1, 0),
+ SOC_SINGLE("Ramp Switch", MAX98927_R0037_AMP_DSP_CFG,
+ MAX98927_AMP_DSP_CFG_RMP_SHIFT, 1, 0),
+ SOC_SINGLE("DRE Switch", MAX98927_R0039_DRE_CTRL,
+ MAX98927_DRE_EN_SHIFT, 1, 0),
+ SOC_SINGLE("Volume Location Switch", MAX98927_R0036_AMP_VOL_CTRL,
+ MAX98927_AMP_VOL_SEL_SHIFT, 1, 0),
+ SOC_ENUM("Boost Output Voltage", max98927_boost_voltage),
+ SOC_ENUM("Current Limit", max98927_current_limit),
+};
+
+static const struct snd_soc_dapm_route max98927_audio_map[] = {
+ {"Amp Enable", NULL, "DAI_OUT"},
+ {"DAI Sel Mux", "Left", "Amp Enable"},
+ {"DAI Sel Mux", "Right", "Amp Enable"},
+ {"DAI Sel Mux", "LeftRight", "Amp Enable"},
+ {"BE_OUT", NULL, "DAI Sel Mux"},
+};
+
+static struct snd_soc_dai_driver max98927_dai[] = {
+ {
+ .name = "max98927-aif1",
+ .playback = {
+ .stream_name = "HiFi Playback",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = MAX98927_RATES,
+ .formats = MAX98927_FORMATS,
+ },
+ .capture = {
+ .stream_name = "HiFi Capture",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = MAX98927_RATES,
+ .formats = MAX98927_FORMATS,
+ },
+ .ops = &max98927_dai_ops,
+ }
+};
+
+static int max98927_probe(struct snd_soc_codec *codec)
+{
+ struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
+
+ max98927->codec = codec;
+ codec->control_data = max98927->regmap;
+ codec->cache_bypass = 1;
+
+ /* Software Reset */
+ regmap_write(max98927->regmap,
+ MAX98927_R0100_SOFT_RESET, MAX98927_SOFT_RESET);
+
+ /* IV default slot configuration */
+ regmap_write(max98927->regmap,
+ MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
+ 0xFF);
+ regmap_write(max98927->regmap,
+ MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
+ 0xFF);
+ regmap_write(max98927->regmap,
+ MAX98927_R0025_PCM_TO_SPK_MONOMIX_A,
+ 0x80);
+ regmap_write(max98927->regmap,
+ MAX98927_R0026_PCM_TO_SPK_MONOMIX_B,
+ 0x1);
+ /* Set inital volume (+13dB) */
+ regmap_write(max98927->regmap,
+ MAX98927_R0036_AMP_VOL_CTRL,
+ 0x38);
+ regmap_write(max98927->regmap,
+ MAX98927_R003C_SPK_GAIN,
+ 0x05);
+ /* Enable DC blocker */
+ regmap_write(max98927->regmap,
+ MAX98927_R0037_AMP_DSP_CFG,
+ 0x03);
+ /* Enable IMON VMON DC blocker */
+ regmap_write(max98927->regmap,
+ MAX98927_R003F_MEAS_DSP_CFG,
+ 0xF7);
+ /* Boost Output Voltage & Current limit */
+ regmap_write(max98927->regmap,
+ MAX98927_R0040_BOOST_CTRL0,
+ 0x1C);
+ regmap_write(max98927->regmap,
+ MAX98927_R0042_BOOST_CTRL1,
+ 0x3E);
+ /* Measurement ADC config */
+ regmap_write(max98927->regmap,
+ MAX98927_R0043_MEAS_ADC_CFG,
+ 0x04);
+ regmap_write(max98927->regmap,
+ MAX98927_R0044_MEAS_ADC_BASE_MSB,
+ 0x00);
+ regmap_write(max98927->regmap,
+ MAX98927_R0045_MEAS_ADC_BASE_LSB,
+ 0x24);
+ /* Brownout Level */
+ regmap_write(max98927->regmap,
+ MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1,
+ 0x06);
+ /* Envelope Tracking configuration */
+ regmap_write(max98927->regmap,
+ MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM,
+ 0x08);
+ regmap_write(max98927->regmap,
+ MAX98927_R0086_ENV_TRACK_CTRL,
+ 0x01);
+ regmap_write(max98927->regmap,
+ MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ,
+ 0x10);
+
+ /* voltage, current slot configuration */
+ regmap_write(max98927->regmap,
+ MAX98927_R001E_PCM_TX_CH_SRC_A,
+ (max98927->i_l_slot<<MAX98927_PCM_TX_CH_SRC_A_I_SHIFT|
+ max98927->v_l_slot)&0xFF);
+
+ if (max98927->v_l_slot < 8) {
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
+ 1 << max98927->v_l_slot, 0);
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001A_PCM_TX_EN_A,
+ 1 << max98927->v_l_slot,
+ 1 << max98927->v_l_slot);
+ } else {
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
+ 1 << (max98927->v_l_slot - 8), 0);
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001B_PCM_TX_EN_B,
+ 1 << (max98927->v_l_slot - 8),
+ 1 << (max98927->v_l_slot - 8));
+ }
+
+ if (max98927->i_l_slot < 8) {
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001C_PCM_TX_HIZ_CTRL_A,
+ 1 << max98927->i_l_slot, 0);
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001A_PCM_TX_EN_A,
+ 1 << max98927->i_l_slot,
+ 1 << max98927->i_l_slot);
+ } else {
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001D_PCM_TX_HIZ_CTRL_B,
+ 1 << (max98927->i_l_slot - 8), 0);
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001B_PCM_TX_EN_B,
+ 1 << (max98927->i_l_slot - 8),
+ 1 << (max98927->i_l_slot - 8));
+ }
+
+ /* Set interleave mode */
+ if (max98927->interleave_mode)
+ regmap_update_bits(max98927->regmap,
+ MAX98927_R001F_PCM_TX_CH_SRC_B,
+ MAX98927_PCM_TX_CH_INTERLEAVE_MASK,
+ MAX98927_PCM_TX_CH_INTERLEAVE_MASK);
+ return 0;
+}
+
+static const struct snd_soc_codec_driver soc_codec_dev_max98927 = {
+ .probe = max98927_probe,
+ .component_driver = {
+ .controls = max98927_snd_controls,
+ .num_controls = ARRAY_SIZE(max98927_snd_controls),
+ .dapm_widgets = max98927_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
+ .dapm_routes = max98927_audio_map,
+ .num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
+ },
+};
+
+static const struct regmap_config max98927_regmap = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = MAX98927_R01FF_REV_ID,
+ .reg_defaults = max98927_reg,
+ .num_reg_defaults = ARRAY_SIZE(max98927_reg),
+ .readable_reg = max98927_readable_register,
+ .volatile_reg = max98927_volatile_reg,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static void max98927_slot_config(struct i2c_client *i2c,
+ struct max98927_priv *max98927)
+{
+ int value;
+
+ if (!of_property_read_u32(i2c->dev.of_node,
+ "vmon-slot-no", &value))
+ max98927->v_l_slot = value & 0xF;
+ else
+ max98927->v_l_slot = 0;
+ if (!of_property_read_u32(i2c->dev.of_node,
+ "imon-slot-no", &value))
+ max98927->i_l_slot = value & 0xF;
+ else
+ max98927->i_l_slot = 1;
+}
+
+static int max98927_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+
+ int ret = 0, value;
+ int reg = 0;
+ struct max98927_priv *max98927 = NULL;
+
+ max98927 = devm_kzalloc(&i2c->dev,
+ sizeof(*max98927), GFP_KERNEL);
+
+ if (!max98927) {
+ ret = -ENOMEM;
+ return ret;
+ }
+ i2c_set_clientdata(i2c, max98927);
+
+ /* update interleave mode info */
+ if (!of_property_read_u32(i2c->dev.of_node,
+ "interleave_mode", &value)) {
+ if (value > 0)
+ max98927->interleave_mode = 1;
+ else
+ max98927->interleave_mode = 0;
+ } else
+ max98927->interleave_mode = 0;
+
+ /* regmap initialization */
+ max98927->regmap
+ = devm_regmap_init_i2c(i2c, &max98927_regmap);
+ if (IS_ERR(max98927->regmap)) {
+ ret = PTR_ERR(max98927->regmap);
+ dev_err(&i2c->dev,
+ "Failed to allocate regmap: %d\n", ret);
+ return ret;
+ }
+
+ /* Check Revision ID */
+ ret = regmap_read(max98927->regmap,
+ MAX98927_R01FF_REV_ID, ®);
+ if (ret < 0) {
+ dev_err(&i2c->dev,
+ "Failed to read: 0x%02X\n", MAX98927_R01FF_REV_ID);
+ return ret;
+ }
+ dev_info(&i2c->dev, "MAX98927 revisionID: 0x%02X\n", reg);
+
+ /* voltage/current slot configuration */
+ max98927_slot_config(i2c, max98927);
+
+ /* codec registeration */
+ ret = snd_soc_register_codec(&i2c->dev, &soc_codec_dev_max98927,
+ max98927_dai, ARRAY_SIZE(max98927_dai));
+ if (ret < 0)
+ dev_err(&i2c->dev, "Failed to register codec: %d\n", ret);
+
+ return ret;
+}
+
+static int max98927_i2c_remove(struct i2c_client *client)
+{
+ snd_soc_unregister_codec(&client->dev);
+ return 0;
+}
+
+static const struct i2c_device_id max98927_i2c_id[] = {
+ { "max98927", 0},
+ { },
+};
+
+MODULE_DEVICE_TABLE(i2c, max98927_i2c_id);
+
+#if defined(CONFIG_OF)
+static const struct of_device_id max98927_of_match[] = {
+ { .compatible = "maxim,max98927", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, max98927_of_match);
+#endif
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id max98927_acpi_match[] = {
+ { "MX98927", 0 },
+ {},
+};
+MODULE_DEVICE_TABLE(acpi, max98927_acpi_match);
+#endif
+
+static struct i2c_driver max98927_i2c_driver = {
+ .driver = {
+ .name = "max98927",
+ .of_match_table = of_match_ptr(max98927_of_match),
+ .acpi_match_table = ACPI_PTR(max98927_acpi_match),
+ .pm = NULL,
+ },
+ .probe = max98927_i2c_probe,
+ .remove = max98927_i2c_remove,
+ .id_table = max98927_i2c_id,
+};
+
+module_i2c_driver(max98927_i2c_driver)
+
+MODULE_DESCRIPTION("ALSA SoC MAX98927 driver");
+MODULE_AUTHOR("Ryan Lee <ryans.lee@maximintegrated.com>");
+MODULE_LICENSE("GPL");
diff --git a/sound/soc/codecs/max98927.h b/sound/soc/codecs/max98927.h
new file mode 100755
index 0000000..ece6a60
--- /dev/null
+++ b/sound/soc/codecs/max98927.h
@@ -0,0 +1,272 @@
+/*
+ * max98927.h -- MAX98927 ALSA Soc Audio driver
+ *
+ * Copyright 2013-15 Maxim Integrated Products
+ * Author: Ryan Lee <ryans.lee@maximintegrated.com>
+ *
+ * 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.
+ *
+ */
+#ifndef _MAX98927_H
+#define _MAX98927_H
+
+/* Register Values */
+#define MAX98927_R0001_INT_RAW1 0x0001
+#define MAX98927_R0002_INT_RAW2 0x0002
+#define MAX98927_R0003_INT_RAW3 0x0003
+#define MAX98927_R0004_INT_STATE1 0x0004
+#define MAX98927_R0005_INT_STATE2 0x0005
+#define MAX98927_R0006_INT_STATE3 0x0006
+#define MAX98927_R0007_INT_FLAG1 0x0007
+#define MAX98927_R0008_INT_FLAG2 0x0008
+#define MAX98927_R0009_INT_FLAG3 0x0009
+#define MAX98927_R000A_INT_EN1 0x000A
+#define MAX98927_R000B_INT_EN2 0x000B
+#define MAX98927_R000C_INT_EN3 0x000C
+#define MAX98927_R000D_INT_FLAG_CLR1 0x000D
+#define MAX98927_R000E_INT_FLAG_CLR2 0x000E
+#define MAX98927_R000F_INT_FLAG_CLR3 0x000F
+#define MAX98927_R0010_IRQ_CTRL 0x0010
+#define MAX98927_R0011_CLK_MON 0x0011
+#define MAX98927_R0012_WDOG_CTRL 0x0012
+#define MAX98927_R0013_WDOG_RST 0x0013
+#define MAX98927_R0014_MEAS_ADC_THERM_WARN_THRESH 0x0014
+#define MAX98927_R0015_MEAS_ADC_THERM_SHDN_THRESH 0x0015
+#define MAX98927_R0016_MEAS_ADC_THERM_HYSTERESIS 0x0016
+#define MAX98927_R0017_PIN_CFG 0x0017
+#define MAX98927_R0018_PCM_RX_EN_A 0x0018
+#define MAX98927_R0019_PCM_RX_EN_B 0x0019
+#define MAX98927_R001A_PCM_TX_EN_A 0x001A
+#define MAX98927_R001B_PCM_TX_EN_B 0x001B
+#define MAX98927_R001C_PCM_TX_HIZ_CTRL_A 0x001C
+#define MAX98927_R001D_PCM_TX_HIZ_CTRL_B 0x001D
+#define MAX98927_R001E_PCM_TX_CH_SRC_A 0x001E
+#define MAX98927_R001F_PCM_TX_CH_SRC_B 0x001F
+#define MAX98927_R0020_PCM_MODE_CFG 0x0020
+#define MAX98927_R0021_PCM_MASTER_MODE 0x0021
+#define MAX98927_R0022_PCM_CLK_SETUP 0x0022
+#define MAX98927_R0023_PCM_SR_SETUP1 0x0023
+#define MAX98927_R0024_PCM_SR_SETUP2 0x0024
+#define MAX98927_R0025_PCM_TO_SPK_MONOMIX_A 0x0025
+#define MAX98927_R0026_PCM_TO_SPK_MONOMIX_B 0x0026
+#define MAX98927_R0027_ICC_RX_EN_A 0x0027
+#define MAX98927_R0028_ICC_RX_EN_B 0x0028
+#define MAX98927_R002B_ICC_TX_EN_A 0x002B
+#define MAX98927_R002C_ICC_TX_EN_B 0x002C
+#define MAX98927_R002E_ICC_HIZ_MANUAL_MODE 0x002E
+#define MAX98927_R002F_ICC_TX_HIZ_EN_A 0x002F
+#define MAX98927_R0030_ICC_TX_HIZ_EN_B 0x0030
+#define MAX98927_R0031_ICC_LNK_EN 0x0031
+#define MAX98927_R0032_PDM_TX_EN 0x0032
+#define MAX98927_R0033_PDM_TX_HIZ_CTRL 0x0033
+#define MAX98927_R0034_PDM_TX_CTRL 0x0034
+#define MAX98927_R0035_PDM_RX_CTRL 0x0035
+#define MAX98927_R0036_AMP_VOL_CTRL 0x0036
+#define MAX98927_R0037_AMP_DSP_CFG 0x0037
+#define MAX98927_R0038_TONE_GEN_DC_CFG 0x0038
+#define MAX98927_R0039_DRE_CTRL 0x0039
+#define MAX98927_R003A_AMP_EN 0x003A
+#define MAX98927_R003B_SPK_SRC_SEL 0x003B
+#define MAX98927_R003C_SPK_GAIN 0x003C
+#define MAX98927_R003D_SSM_CFG 0x003D
+#define MAX98927_R003E_MEAS_EN 0x003E
+#define MAX98927_R003F_MEAS_DSP_CFG 0x003F
+#define MAX98927_R0040_BOOST_CTRL0 0x0040
+#define MAX98927_R0041_BOOST_CTRL3 0x0041
+#define MAX98927_R0042_BOOST_CTRL1 0x0042
+#define MAX98927_R0043_MEAS_ADC_CFG 0x0043
+#define MAX98927_R0044_MEAS_ADC_BASE_MSB 0x0044
+#define MAX98927_R0045_MEAS_ADC_BASE_LSB 0x0045
+#define MAX98927_R0046_ADC_CH0_DIVIDE 0x0046
+#define MAX98927_R0047_ADC_CH1_DIVIDE 0x0047
+#define MAX98927_R0048_ADC_CH2_DIVIDE 0x0048
+#define MAX98927_R0049_ADC_CH0_FILT_CFG 0x0049
+#define MAX98927_R004A_ADC_CH1_FILT_CFG 0x004A
+#define MAX98927_R004B_ADC_CH2_FILT_CFG 0x004B
+#define MAX98927_R004C_MEAS_ADC_CH0_READ 0x004C
+#define MAX98927_R004D_MEAS_ADC_CH1_READ 0x004D
+#define MAX98927_R004E_MEAS_ADC_CH2_READ 0x004E
+#define MAX98927_R0051_BROWNOUT_STATUS 0x0051
+#define MAX98927_R0052_BROWNOUT_EN 0x0052
+#define MAX98927_R0053_BROWNOUT_INFINITE_HOLD 0x0053
+#define MAX98927_R0054_BROWNOUT_INFINITE_HOLD_CLR 0x0054
+#define MAX98927_R0055_BROWNOUT_LVL_HOLD 0x0055
+#define MAX98927_R005A_BROWNOUT_LVL1_THRESH 0x005A
+#define MAX98927_R005B_BROWNOUT_LVL2_THRESH 0x005B
+#define MAX98927_R005C_BROWNOUT_LVL3_THRESH 0x005C
+#define MAX98927_R005D_BROWNOUT_LVL4_THRESH 0x005D
+#define MAX98927_R005E_BROWNOUT_THRESH_HYSTERYSIS 0x005E
+#define MAX98927_R005F_BROWNOUT_AMP_LIMITER_ATK_REL 0x005F
+#define MAX98927_R0060_BROWNOUT_AMP_GAIN_ATK_REL 0x0060
+#define MAX98927_R0061_BROWNOUT_AMP1_CLIP_MODE 0x0061
+#define MAX98927_R0072_BROWNOUT_LVL1_CUR_LIMIT 0x0072
+#define MAX98927_R0073_BROWNOUT_LVL1_AMP1_CTRL1 0x0073
+#define MAX98927_R0074_BROWNOUT_LVL1_AMP1_CTRL2 0x0074
+#define MAX98927_R0075_BROWNOUT_LVL1_AMP1_CTRL3 0x0075
+#define MAX98927_R0076_BROWNOUT_LVL2_CUR_LIMIT 0x0076
+#define MAX98927_R0077_BROWNOUT_LVL2_AMP1_CTRL1 0x0077
+#define MAX98927_R0078_BROWNOUT_LVL2_AMP1_CTRL2 0x0078
+#define MAX98927_R0079_BROWNOUT_LVL2_AMP1_CTRL3 0x0079
+#define MAX98927_R007A_BROWNOUT_LVL3_CUR_LIMIT 0x007A
+#define MAX98927_R007B_BROWNOUT_LVL3_AMP1_CTRL1 0x007B
+#define MAX98927_R007C_BROWNOUT_LVL3_AMP1_CTRL2 0x007C
+#define MAX98927_R007D_BROWNOUT_LVL3_AMP1_CTRL3 0x007D
+#define MAX98927_R007E_BROWNOUT_LVL4_CUR_LIMIT 0x007E
+#define MAX98927_R007F_BROWNOUT_LVL4_AMP1_CTRL1 0x007F
+#define MAX98927_R0080_BROWNOUT_LVL4_AMP1_CTRL2 0x0080
+#define MAX98927_R0081_BROWNOUT_LVL4_AMP1_CTRL3 0x0081
+#define MAX98927_R0082_ENV_TRACK_VOUT_HEADROOM 0x0082
+#define MAX98927_R0083_ENV_TRACK_BOOST_VOUT_DELAY 0x0083
+#define MAX98927_R0084_ENV_TRACK_REL_RATE 0x0084
+#define MAX98927_R0085_ENV_TRACK_HOLD_RATE 0x0085
+#define MAX98927_R0086_ENV_TRACK_CTRL 0x0086
+#define MAX98927_R0087_ENV_TRACK_BOOST_VOUT_READ 0x0087
+#define MAX98927_R00FF_GLOBAL_SHDN 0x00FF
+#define MAX98927_R0100_SOFT_RESET 0x0100
+#define MAX98927_R01FF_REV_ID 0x01FF
+
+/* MAX98927_R0018_PCM_RX_EN_A */
+#define MAX98927_PCM_RX_CH0_EN (0x1 << 0)
+#define MAX98927_PCM_RX_CH1_EN (0x1 << 1)
+#define MAX98927_PCM_RX_CH2_EN (0x1 << 2)
+#define MAX98927_PCM_RX_CH3_EN (0x1 << 3)
+#define MAX98927_PCM_RX_CH4_EN (0x1 << 4)
+#define MAX98927_PCM_RX_CH5_EN (0x1 << 5)
+#define MAX98927_PCM_RX_CH6_EN (0x1 << 6)
+#define MAX98927_PCM_RX_CH7_EN (0x1 << 7)
+
+/* MAX98927_R001A_PCM_TX_EN_A */
+#define MAX98927_PCM_TX_CH0_EN (0x1 << 0)
+#define MAX98927_PCM_TX_CH1_EN (0x1 << 1)
+#define MAX98927_PCM_TX_CH2_EN (0x1 << 2)
+#define MAX98927_PCM_TX_CH3_EN (0x1 << 3)
+#define MAX98927_PCM_TX_CH4_EN (0x1 << 4)
+#define MAX98927_PCM_TX_CH5_EN (0x1 << 5)
+#define MAX98927_PCM_TX_CH6_EN (0x1 << 6)
+#define MAX98927_PCM_TX_CH7_EN (0x1 << 7)
+
+/* MAX98927_R001E_PCM_TX_CH_SRC_A */
+#define MAX98927_PCM_TX_CH_SRC_A_V_SHIFT (0)
+#define MAX98927_PCM_TX_CH_SRC_A_I_SHIFT (4)
+
+/* MAX98927_R001F_PCM_TX_CH_SRC_B */
+#define MAX98927_PCM_TX_CH_INTERLEAVE_MASK (0x1 << 5)
+
+/* MAX98927_R0020_PCM_MODE_CFG */
+#define MAX98927_PCM_MODE_CFG_PCM_BCLKEDGE (0x1 << 2)
+#define MAX98927_PCM_MODE_CFG_FORMAT_MASK (0x7 << 3)
+#define MAX98927_PCM_MODE_CFG_FORMAT_SHIFT (3)
+#define MAX98927_PCM_FORMAT_I2S (0x0 << 0)
+#define MAX98927_PCM_FORMAT_LJ (0x1 << 0)
+
+#define MAX98927_PCM_MODE_CFG_CHANSZ_MASK (0x3 << 6)
+#define MAX98927_PCM_MODE_CFG_CHANSZ_16 (0x1 << 6)
+#define MAX98927_PCM_MODE_CFG_CHANSZ_24 (0x2 << 6)
+#define MAX98927_PCM_MODE_CFG_CHANSZ_32 (0x3 << 6)
+
+/* MAX98927_R0021_PCM_MASTER_MODE */
+#define MAX98927_PCM_MASTER_MODE_MASK (0x3 << 0)
+#define MAX98927_PCM_MASTER_MODE_SLAVE (0x0 << 0)
+#define MAX98927_PCM_MASTER_MODE_MASTER (0x3 << 0)
+
+#define MAX98927_PCM_MASTER_MODE_MCLK_MASK (0xF << 2)
+#define MAX98927_PCM_MASTER_MODE_MCLK_RATE_SHIFT (2)
+
+/* MAX98927_R0022_PCM_CLK_SETUP */
+#define MAX98927_PCM_CLK_SETUP_BSEL_MASK (0xF << 0)
+
+/* MAX98927_R0023_PCM_SR_SETUP1 */
+#define MAX98927_PCM_SR_SET1_SR_MASK (0xF << 0)
+
+#define MAX98927_PCM_SR_SET1_SR_8000 (0x0 << 0)
+#define MAX98927_PCM_SR_SET1_SR_11025 (0x1 << 0)
+#define MAX98927_PCM_SR_SET1_SR_12000 (0x2 << 0)
+#define MAX98927_PCM_SR_SET1_SR_16000 (0x3 << 0)
+#define MAX98927_PCM_SR_SET1_SR_22050 (0x4 << 0)
+#define MAX98927_PCM_SR_SET1_SR_24000 (0x5 << 0)
+#define MAX98927_PCM_SR_SET1_SR_32000 (0x6 << 0)
+#define MAX98927_PCM_SR_SET1_SR_44100 (0x7 << 0)
+#define MAX98927_PCM_SR_SET1_SR_48000 (0x8 << 0)
+
+/* MAX98927_R0024_PCM_SR_SETUP2 */
+#define MAX98927_PCM_SR_SET2_SR_MASK (0xF << 4)
+#define MAX98927_PCM_SR_SET2_SR_SHIFT (4)
+#define MAX98927_PCM_SR_SET2_IVADC_SR_MASK (0xf << 0)
+
+/* MAX98927_R0025_PCM_TO_SPK_MONOMIX_A */
+#define MAX98927_PCM_TO_SPK_MONOMIX_CFG_MASK (0x3 << 6)
+#define MAX98927_PCM_TO_SPK_MONOMIX_CFG_SHIFT (6)
+
+/* MAX98927_R0035_PDM_RX_CTRL */
+#define MAX98927_PDM_RX_EN_MASK (0x1 << 0)
+
+/* MAX98927_R0036_AMP_VOL_CTRL */
+#define MAX98927_AMP_VOL_SEL (0x1 << 7)
+#define MAX98927_AMP_VOL_SEL_WIDTH (1)
+#define MAX98927_AMP_VOL_SEL_SHIFT (7)
+#define MAX98927_AMP_VOL_MASK (0x7f << 0)
+#define MAX98927_AMP_VOL_WIDTH (7)
+#define MAX98927_AMP_VOL_SHIFT (0)
+
+/* MAX98927_R0037_AMP_DSP_CFG */
+#define MAX98927_AMP_DSP_CFG_DCBLK_EN (0x1 << 0)
+#define MAX98927_AMP_DSP_CFG_DITH_EN (0x1 << 1)
+#define MAX98927_AMP_DSP_CFG_RMP_BYPASS (0x1 << 4)
+#define MAX98927_AMP_DSP_CFG_DAC_INV (0x1 << 5)
+#define MAX98927_AMP_DSP_CFG_RMP_SHIFT (4)
+
+/* MAX98927_R0039_DRE_CTRL */
+#define MAX98927_DRE_CTRL_DRE_EN (0x1 << 0)
+#define MAX98927_DRE_EN_SHIFT 0x1
+
+/* MAX98927_R003A_AMP_EN */
+#define MAX98927_AMP_EN_MASK (0x1 << 0)
+
+/* MAX98927_R003B_SPK_SRC_SEL */
+#define MAX98927_SPK_SRC_MASK (0x3 << 0)
+
+/* MAX98927_R003C_SPK_GAIN */
+#define MAX98927_SPK_PCM_GAIN_MASK (0x7 << 0)
+#define MAX98927_SPK_PDM_GAIN_MASK (0x7 << 4)
+#define MAX98927_SPK_GAIN_WIDTH (3)
+
+/* MAX98927_R003E_MEAS_EN */
+#define MAX98927_MEAS_V_EN (0x1 << 0)
+#define MAX98927_MEAS_I_EN (0x1 << 1)
+
+/* MAX98927_R0040_BOOST_CTRL0 */
+#define MAX98927_BOOST_CTRL0_VOUT_MASK (0x1f << 0)
+#define MAX98927_BOOST_CTRL0_PVDD_MASK (0x1 << 7)
+#define MAX98927_BOOST_CTRL0_PVDD_EN_SHIFT (7)
+
+/* MAX98927_R0052_BROWNOUT_EN */
+#define MAX98927_BROWNOUT_BDE_EN (0x1 << 0)
+#define MAX98927_BROWNOUT_AMP_EN (0x1 << 1)
+#define MAX98927_BROWNOUT_DSP_EN (0x1 << 2)
+#define MAX98927_BROWNOUT_DSP_SHIFT (2)
+
+/* MAX98927_R0100_SOFT_RESET */
+#define MAX98927_SOFT_RESET (0x1 << 0)
+
+/* MAX98927_R00FF_GLOBAL_SHDN */
+#define MAX98927_GLOBAL_EN_MASK (0x1 << 0)
+
+struct max98927_priv {
+ struct regmap *regmap;
+ struct snd_soc_codec *codec;
+ struct max98927_pdata *pdata;
+ unsigned int spk_gain;
+ unsigned int sysclk;
+ unsigned int v_l_slot;
+ unsigned int i_l_slot;
+ bool interleave_mode;
+ unsigned int ch_size;
+ unsigned int rate;
+ unsigned int iface;
+ unsigned int master;
+ unsigned int digital_gain;
+};
+#endif
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3] ASoC: Add support for Maxim Integrated MAX98927 Amplifier
From: Ryan Lee @ 2017-03-31 1:18 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
Kuninori Morimoto, Arnd Bergmann,
ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
lars-Qo5EllUWu/uELgA04lAiVw, bardliao-Rasf1IRRPZFBDgjK7y7TUQ,
nh6z-fFIq/eER6g8, KCHSU0-KrzQf0k3Iz9BDgjK7y7TUQ, Axel Lin,
romain.perier-ZGY8ohtN/8qB+jHODAdFcQ, Srinivas Kandagatla,
oder_chiou-Rasf1IRRPZFBDgjK7y7TUQ,
Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dylan Reid
In-Reply-To: <20170329142304.qovnyqd6izackny2-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Wed, Mar 29, 2017 at 7:23 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Mar 29, 2017 at 09:53:48AM +0900, Ryan Lee wrote:
>
>> + case SND_SOC_DAIFMT_CBS_CFM:
>> + mode = MAX98927_PCM_MASTER_MODE_HYBRID;
>> + default:
>> + dev_err(codec->dev, "DAI clock mode unsupported");
>
> Either we don't support _CBS_CFM or there's a missing break there.
This was removed since CVS_CFM is not supported.
>
>> + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
>> + case SND_SOC_DAIFMT_I2S:
>> + max98927->iface |= SND_SOC_DAIFMT_I2S;
>> +
>> + break;
>
> Please use the kernel coding style as you do in the rest of this
> function.
Modified as requested.
>
>> + int reg = MAX98927_R0022_PCM_CLK_SETUP;
>> + int mask = MAX98927_PCM_CLK_SETUP_BSEL_MASK;
>
>> + regmap_update_bits(max98927->regmap, reg, mask, value);
>
> reg and mask have exactly one user (as you'd expect), just use the
> constants directly here to make things clearer.
Removed reg and mask.
>
>> + switch (snd_pcm_format_width(params_format(params))) {
>> + case 16:
>> + chan_sz = MAX98927_PCM_MODE_CFG_CHANSZ_16;
>> + max98927->ch_size = 16;
>
> You could just assign ch_size directly.
Sorry I don't fully understand this.
Anyway 'ch_size' will be directly updated from snd_pcm_format_width
information after modification.
>
>> + /* sampling rate configuration */
>> + switch (params_rate(params)) {
>> + case 8000:
>> + sampling_rate |= MAX98927_PCM_SR_SET1_SR_8000;
>
> sampling_rate is only ever set to a real value in this switch statement,
> you're not oring with anything else so you can just use an assignment
> which would be a lot clearer (it's not obvious what else might go in
> there) and the initial assignment to 0 for this and chan_sz can only
> mask errors.
Removed 'oring'.
>
>> + /* set sampling rate of IV */
>> + if (max98927->interleave_mode &&
>> + sampling_rate > MAX98927_PCM_SR_SET1_SR_16000)
>> + regmap_update_bits(max98927->regmap,
>
> Please use the kernel coding style, indent the second line of the if
> with the ( so that it doesn't look like part of the conditional code.
Modified as requested.
>
>> + switch (reg) {
>> + case MAX98927_R0001_INT_RAW1 ... MAX98927_R0028_ICC_RX_EN_B:
>
>
>> + return true;
>> + }
>> + return false;
>
> It'd be clearer to put the return false in the switch statement like the
> return true, and also consistent with the _volatile_reg() function.
Modified as requested.
>
>> +static const char * const max98927_speaker_source_text[] = {
>> + "i2s", "reserved", "tone", "pdm"
>> +};
>
> This looks like it should be a DAPM control.
Removed this and added it to 'dai_set_format' function.
>
>> +static const char * const max98927_monomix_output_text[] = {
>> + "ch_0", "ch_1", "ch_1_2_div"
>> +};
>
> Similarly here.
Removed this since it was already added to DAPM control.
>
>> + SOC_SINGLE_TLV("Digital Gain", MAX98927_R0036_AMP_VOL_CTRL,
>> + 0, (1<<MAX98927_AMP_VOL_WIDTH)-1, 0,
>> + max98927_digital_tlv),
>
> All volume controls should end with Volume as per control-names.rst.
Modified as requested.
>
>> + SOC_SINGLE("Amp DSP Enable", MAX98927_R0052_BROWNOUT_EN,
>> + MAX98927_BROWNOUT_DSP_SHIFT, 1, 0),
>
> All on/off switches should end with Switch as per control-names.rst.
Modified as requested.
>
>> +static int max98927_probe(struct snd_soc_codec *codec)
>> +{
>
>> + /* Check Revision ID */
>> + ret = regmap_read(max98927->regmap,
>> + MAX98927_R01FF_REV_ID, ®);
>
> Basic device identification and setup should be done at the chip level
> probe not at the CODEC level so that if there are problems we fail as
> early as possible and so that diagnostic information is available to
> users as soon as possible, even if there's no sound card for the device
> in the system.
Moved to i2c_probe function.
>
>> + /* Set inital volume (+13dB) */
>
> As with all other CODEC drivers you should leave the hardware defaults
> alone, what makes sense for your system may not make sense for other
> systems and the hardware defaults are a fixed thing.
We recommend to use static +13dB gain when our speaker protection
algorithm is running on DSP. It is not hardware default but mostly
+13dB is being used as default.
>
>> + /* Boost Output Voltage & Current limit */
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0040_BOOST_CTRL0,
>> + 0x1C);
>> + regmap_write(max98927->regmap,
>> + MAX98927_R0042_BOOST_CTRL1,
>> + 0x3E);
>
> This should be system specific, these values might be unsafe in some
> systems.
Same as above, most user will use maximum voltage & current limit
value to take advantage of 10V boost amplifier.
I added one more control to change the current limit value.
>
>> +err:
>> + if (max98927)
>> + devm_kfree(&i2c->dev, max98927);
>
> There is no need to explicitly free devm_ allocated memory, that's the
> point of devm.
Removed the code.
--
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 1/3] dts: arm64: add DPAA QBMan portals
From: Shawn Guo @ 2017-03-31 1:49 UTC (permalink / raw)
To: Madalin Bucur
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gang.Liu-3arQi8VN3Tc,
catalin.marinas-5wv7dgnIgG8, Roy Pledge, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490884672-18294-2-git-send-email-madalin.bucur-3arQi8VN3Tc@public.gmane.org>
On Thu, Mar 30, 2017 at 05:37:50PM +0300, Madalin Bucur wrote:
> Add the DPAA 1.x DPAA QMan and BMan portal nodes.
>
> Signed-off-by: Roy Pledge <roy.pledge-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Madalin Bucur <madalin.bucur-3arQi8VN3Tc@public.gmane.org>
The patches should be prefixed like 'arm64: dts: ...'.
> ---
> .../boot/dts/freescale/qoriq-bman1-portals.dtsi | 67 +++++++++++++++++++
> .../boot/dts/freescale/qoriq-qman1-portals.dtsi | 76 ++++++++++++++++++++++
> 2 files changed, 143 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
> create mode 100644 arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi
What does the suffix number '1' mean here?
>
> diff --git a/arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi b/arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
> new file mode 100644
> index 0000000..b007344
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/qoriq-bman1-portals.dtsi
> @@ -0,0 +1,67 @@
> +/*
> + * QorIQ BMan Portals device tree
> + *
> + * Copyright 2011-2016 Freescale Semiconductor Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> + */
> +
> +&bportals {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> +
> + bman-portal@0 {
> + compatible = "fsl,bman-portal";
The bindings/soc/fsl/bman-portals.txt says: Must include
"fsl,bman-portal-<hardware revision>".
> + reg = <0x0 0x4000 0x4000000 0x4000>;
Can we write it in the same way how the example in the bindings doc
does?
reg = <0x0 0x4000>, <0x4000000 0x4000>;
It's more obvious to tell that it has two memory regions.
> + interrupts = <0 173 0x4>;
Can we use GIC_SPI and IRQ_TYPE_LEVEL_HIGH which are defined by
headers in include/dt-bindings/interrupt-controller/ to make it more
readable?
Shawn
> + };
> +
> + bman-portal@10000 {
> + compatible = "fsl,bman-portal";
> + reg = <0x10000 0x4000 0x4010000 0x4000>;
> + interrupts = <0 175 0x4>;
> + };
> +
> + bman-portal@20000 {
> + compatible = "fsl,bman-portal";
> + reg = <0x20000 0x4000 0x4020000 0x4000>;
> + interrupts = <0 177 0x4>;
> + };
> +
> + bman-portal@30000 {
> + compatible = "fsl,bman-portal";
> + reg = <0x30000 0x4000 0x4030000 0x4000>;
> + interrupts = <0 179 0x4>;
> + };
> +
> + bman-portal@40000 {
> + compatible = "fsl,bman-portal";
> + reg = <0x40000 0x4000 0x4040000 0x4000>;
> + interrupts = <0 181 0x4>;
> + };
> +
> + bman-portal@50000 {
> + compatible = "fsl,bman-portal";
> + reg = <0x50000 0x4000 0x4050000 0x4000>;
> + interrupts = <0 183 0x4>;
> + };
> +
> + bman-portal@60000 {
> + compatible = "fsl,bman-portal";
> + reg = <0x60000 0x4000 0x4060000 0x4000>;
> + interrupts = <0 185 0x4>;
> + };
> +
> + bman-portal@70000 {
> + compatible = "fsl,bman-portal";
> + reg = <0x70000 0x4000 0x4070000 0x4000>;
> + interrupts = <0 187 0x4>;
> + };
> +
> + bman-portal@80000 {
> + compatible = "fsl,bman-portal";
> + reg = <0x80000 0x4000 0x4080000 0x4000>;
> + interrupts = <0 189 0x4>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi b/arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi
> new file mode 100644
> index 0000000..4baec2c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/qoriq-qman1-portals.dtsi
> @@ -0,0 +1,76 @@
> +/*
> + * QorIQ QMan Portals device tree
> + *
> + * Copyright 2011-2016 Freescale Semiconductor Inc.
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> + */
> +
> +&qportals {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> +
> + qportal0: qman-portal@0 {
> + compatible = "fsl,qman-portal";
> + reg = <0x0 0x4000 0x4000000 0x4000>;
> + interrupts = <0 172 0x4>;
> + cell-index = <0>;
> + };
> +
> + qportal1: qman-portal@10000 {
> + compatible = "fsl,qman-portal";
> + reg = <0x10000 0x4000 0x4010000 0x4000>;
> + interrupts = <0 174 0x4>;
> + cell-index = <1>;
> + };
> +
> + qportal2: qman-portal@20000 {
> + compatible = "fsl,qman-portal";
> + reg = <0x20000 0x4000 0x4020000 0x4000>;
> + interrupts = <0 176 0x4>;
> + cell-index = <2>;
> + };
> +
> + qportal3: qman-portal@30000 {
> + compatible = "fsl,qman-portal";
> + reg = <0x30000 0x4000 0x4030000 0x4000>;
> + interrupts = <0 178 0x4>;
> + cell-index = <3>;
> + };
> +
> + qportal4: qman-portal@40000 {
> + compatible = "fsl,qman-portal";
> + reg = <0x40000 0x4000 0x4040000 0x4000>;
> + interrupts = <0 180 0x4>;
> + cell-index = <4>;
> + };
> +
> + qportal5: qman-portal@50000 {
> + compatible = "fsl,qman-portal";
> + reg = <0x50000 0x4000 0x4050000 0x4000>;
> + interrupts = <0 182 0x4>;
> + cell-index = <5>;
> + };
> +
> + qportal6: qman-portal@60000 {
> + compatible = "fsl,qman-portal";
> + reg = <0x60000 0x4000 0x4060000 0x4000>;
> + interrupts = <0 184 0x4>;
> + cell-index = <6>;
> + };
> +
> + qportal7: qman-portal@70000 {
> + compatible = "fsl,qman-portal";
> + reg = <0x70000 0x4000 0x4070000 0x4000>;
> + interrupts = <0 186 0x4>;
> + cell-index = <7>;
> + };
> +
> + qportal8: qman-portal@80000 {
> + compatible = "fsl,qman-portal";
> + reg = <0x80000 0x4000 0x4080000 0x4000>;
> + interrupts = <0 188 0x4>;
> + cell-index = <8>;
> + };
> +};
> --
> 2.1.0
>
>
> _______________________________________________
> 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 2/3] dts: arm64: add LS1043A DPAA QBMan nodes
From: Shawn Guo @ 2017-03-31 2:02 UTC (permalink / raw)
To: Madalin Bucur
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, Gang.Liu-3arQi8VN3Tc, Roy Pledge
In-Reply-To: <1490884672-18294-3-git-send-email-madalin.bucur-3arQi8VN3Tc@public.gmane.org>
On Thu, Mar 30, 2017 at 05:37:51PM +0300, Madalin Bucur wrote:
> Add the DPAA 1.x QMan and BMan nodes in the LS1043A device tree.
>
> Signed-off-by: Roy Pledge <roy.pledge-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Madalin Bucur <madalin.bucur-3arQi8VN3Tc@public.gmane.org>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 52 ++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index ec13a6e..8434e89 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> @@ -106,6 +106,33 @@
> /* DRAM space 1, size: 2GiB DRAM */
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + bman_fbpr: bman-fbpr {
> + compatible = "shared-dma-pool";
> + size = <0 0x1000000>;
> + alignment = <0 0x1000000>;
> + no-map;
> + };
> +
> + qman_fqd: qman-fqd {
> + compatible = "shared-dma-pool";
> + size = <0 0x400000>;
> + alignment = <0 0x400000>;
> + no-map;
> + };
> +
> + qman_pfdr: qman-pfdr {
> + compatible = "shared-dma-pool";
> + size = <0 0x2000000>;
> + alignment = <0 0x2000000>;
> + no-map;
> + };
> + };
> +
> sysclk: sysclk {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> @@ -333,6 +360,28 @@
> };
> };
>
> + qman: qman@1880000 {
> + compatible = "fsl,qman";
> + reg = <0x00 0x1880000 0x0 0x10000>;
s/0x00/0x0?
Shawn
> + interrupts = <0 45 0x4>;
> + memory-region = <&qman_fqd &qman_pfdr>;
> + };
> +
> + bman: bman@1890000 {
> + compatible = "fsl,bman";
> + reg = <0x00 0x1890000 0x0 0x10000>;
> + interrupts = <0 45 0x4>;
> + memory-region = <&bman_fbpr>;
> + };
> +
> + bportals: bman-portals@508000000 {
> + ranges = <0x0 0x5 0x08000000 0x8000000>;
> + };
> +
> + qportals: qman-portals@500000000 {
> + ranges = <0x0 0x5 0x00000000 0x8000000>;
> + };
> +
> dspi0: dspi@2100000 {
> compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
> #address-cells = <1>;
> @@ -686,3 +735,6 @@
> };
>
> };
> +
> +#include "qoriq-qman1-portals.dtsi"
> +#include "qoriq-bman1-portals.dtsi"
> --
> 2.1.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 v7 00/13] mmc: Add support to Marvell Xenon SD Host Controller
From: Hu Ziji @ 2017-03-31 2:09 UTC (permalink / raw)
To: Russell King - ARM Linux, Gregory CLEMENT
Cc: Ulf Hansson, Adrian Hunter, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Jimmy Xu, Andrew Lunn, Mike Turquette, Nadav Haklai, Victor Gu,
Doug Jones, linux-clk-u79uwXL29TY76Z2rM5mHXA, Jisheng Zhang,
Yehuda Yitschak, Marcin Wojtas, Kostya Porotchkin, Hanna Hawa,
Sebastian Hesselbarth, devicetree-u79uwXL29TY76Z2rM5mHXA,
Jason Cooper, Rob Herring, Ryan Gao, Wei(SOCP) Liu,
linux-arm-kernel-IAPFreCvJWNGWvitb5QawA
In-Reply-To: <20170330185639.GI7909-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Hi Russell,
On 2017/3/31 2:56, Russell King - ARM Linux wrote:
> ----------------------------------------------------------------------
> On Thu, Mar 30, 2017 at 05:22:52PM +0200, Gregory CLEMENT wrote:
>> - Remove parse of child node mmc-card. Wait for a better solution.
>
> So for mcbin, I have:
>
> &ap_sdhci0 {
> bus-width = <8>;
> marvell,xenon-emmc;
> marvell,xenon-phy-type = "emmc 5.1 phy";
> /*
> * Not stable in HS modes - phy needs "more calibration", so add
> * the "slow-mode" and disable SDR104, SDR50 and DDR50 modes.
> */
> marvell,xenon-phy-slow-mode;
> no-1-8-v;
> non-removable;
> status = "okay";
> vqmmc-supply = <&v_vddo_h>;
>
> #address-cells = <1>;
> #size-cells = <0>;
> mmccard: mmccard@0 {
> compatible = "mmc-card";
> reg = <0>;
> };
> };
>
> Does this mean the "mmccard" bit is no longer required - or is it required
> for the eMMC to be detected but is no longer supported by the driver?
>
Based on the implementation in this release, "mmccard" is no longer required.
More details:
eMMC Vqmmc in Xenon is fixed without a regulator. Thus 1.8V Signaling Enable bit
in SDHC doesn't work.
As a result, Xenon driver has to skip sdhci_start_signal_voltage_switch() to avoid
checking 1.8V signaling enable bit when setting signaling voltage.
Previously, we use "mmccard" to inform Xenon driver that it is an eMMC card
and therefore sdhci_start_signal_voltage_switch() is skipped.
Currently, Xenon driver directly checks if Vqmmc regulator is provided.
Skip sdhci_start_signal_voltage_switch() if Vqmmc is fixed.
In my own opinion, it is more direct and clear, than checking eMMC card type.
Thank you.
Best regards,
Hu Ziji
> Thanks.
>
--
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 V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
From: Guochun Mao @ 2017-03-31 2:26 UTC (permalink / raw)
To: Cyrille Pitchen, Marek Vasut
Cc: Boris Brezillon, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Richard Weinberger, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Cyrille Pitchen,
David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <24d60072-4124-7ec4-6cd3-fd70f4f6b10a-yU5RGvR974pGWvitb5QawA@public.gmane.org>
Hi Cyrille, Marek,
Thanks for your suggestions.
On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
> Hi Guochun,
>
> Le 30/03/2017 à 10:23, Guochun Mao a écrit :
> > when nor's size larger than 16MByte, nor and controller should
> > enter 4Byte mode simultaneously.
> >
> > Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/mtd/spi-nor/mtk-quadspi.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> > index e661877..05cd8a8 100644
> > --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> > @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> > /* We only handle 1 byte */
> > ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
> > break;
> > + case SPINOR_OP_EN4B:
> > + /* Set nor controller to 4-byte address mode,
> > + * and simultaneously set nor flash.
> > + * This case should cooperate with default operation.
> > + */
> > + writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
> > + mt8173_nor->base + MTK_NOR_DUAL_REG);
>
> This is not good: you should check in both mt8173_nor_read() and
> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
>
> from include/linux/mtd/spi-nor.h:
> * @addr_width: number of address bytes
>
> Besides SPI commands using an op code from 4-byte address instruction
> set always carry a 4-byte address. They can be used directly, without
> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
> will be 4-byte long only if your SPI controller driver has seen a
> SPINOR_OP_EN4B command before. This assumption is wrong.
Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
modified in later process.
Does it means that we will not switch nor between 3Byte address and
4Byte?
So, is it better to check nor->addr_width when do nor initialization?
>
> SPI controller driver should never check SPINOR_OP_* op codes like this.
I agree that SPI controller driver should not check SPINOR_OP_* op codes
like what I do.
I will correct it next version.
Best Regards,
Guochun
>
> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
> op codes may change depending on the memory manufacturer. So testing op
> code values like you do can work with some memories but maybe not all.
>
> Finally, don't use 0x10, please define a macro instead.
>
> Best regards,
>
> Cyrille
>
> > default:
> > ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
> > if (ret)
> >
>
--
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 3/3] dts: arm64: add LS1046A DPAA QBMan nodes
From: Shawn Guo @ 2017-03-31 2:29 UTC (permalink / raw)
To: Madalin Bucur
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, Gang.Liu-3arQi8VN3Tc, Roy Pledge
In-Reply-To: <1490884672-18294-4-git-send-email-madalin.bucur-3arQi8VN3Tc@public.gmane.org>
On Thu, Mar 30, 2017 at 05:37:52PM +0300, Madalin Bucur wrote:
> Add the QBMan device tree nodes for LS1046A devices.
>
> Signed-off-by: Roy Pledge <roy.pledge-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Madalin Bucur <madalin.bucur-3arQi8VN3Tc@public.gmane.org>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 52 ++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> index 4a164b8..67e073a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
> @@ -268,6 +268,30 @@
> };
> };
>
> + qman: qman@1880000 {
> + compatible = "fsl,qman";
> + reg = <0x00 0x1880000 0x0 0x10000>;
> + interrupts = <0 45 0x4>;
> + memory-region = <&qman_fqd &qman_pfdr>;
> +
> + };
> +
> + bman: bman@1890000 {
> + compatible = "fsl,bman";
> + reg = <0x00 0x1890000 0x0 0x10000>;
> + interrupts = <0 45 0x4>;
> + memory-region = <&bman_fbpr>;
> +
> + };
> +
> + qportals: qman-portals@500000000 {
> + ranges = <0x0 0x5 0x00000000 0x8000000>;
> + };
> +
> + bportals: bman-portals@508000000 {
> + ranges = <0x0 0x5 0x08000000 0x8000000>;
> + };
> +
> dcfg: dcfg@1ee0000 {
> compatible = "fsl,ls1046a-dcfg", "syscon";
> reg = <0x0 0x1ee0000 0x0 0x10000>;
> @@ -592,4 +616,32 @@
> clocks = <&clockgen 4 1>;
> };
> };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + bman_fbpr: bman-fbpr {
> + compatible = "shared-dma-pool";
> + size = <0 0x1000000>;
> + alignment = <0 0x1000000>;
> + no-map;
> + };
Please have a newline between nodes.
Shawn
> + qman_fqd: qman-fqd {
> + compatible = "shared-dma-pool";
> + size = <0 0x800000>;
> + alignment = <0 0x800000>;
> + no-map;
> + };
> + qman_pfdr: qman-pfdr {
> + compatible = "shared-dma-pool";
> + size = <0 0x2000000>;
> + alignment = <0 0x2000000>;
> + no-map;
> + };
> + };
> };
> +
> +#include "qoriq-qman1-portals.dtsi"
> +#include "qoriq-bman1-portals.dtsi"
> --
> 2.1.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: Recommended notation for OPP to avoid DTC warnings
From: Masahiro Yamada @ 2017-03-31 2:59 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Rutland, Rob Herring, linux-pm, devicetree, linux-arm-kernel,
Linux Kernel Mailing List
In-Reply-To: <20170227105533.GA19417@vireshk-i7>
Hi.
2017-02-27 19:55 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
> On 27-02-17, 10:44, Mark Rutland wrote:
>> On Sun, Feb 26, 2017 at 02:18:03PM +0900, Masahiro Yamada wrote:
>> > Hi.
>> >
>> >
>> > Decumentation/devicetree/bindings/opp/opp.txt
>> > takes examples like this:
>> >
>> > opp@1000000000 {
>> > opp-hz = /bits/ 64 <1000000000>;
>> > opp-microvolt = <970000 975000 985000>;
>> > opp-microamp = <70000>;
>> > clock-latency-ns = <300000>;
>> > opp-suspend;
>> > };
>>
>> > If we follow this notation and the device-tree is built 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
>> >
>> > Is there a recommended notation to avoid it?
>> >
>> > Maybe, simply omit the "@" ?
>>
>> I think just s/@/-/ should be fine, e.g. call the above opp-1000000000.
>
> That's fine with me. I can send a patch to fix all existing users if we all
> agree for it.
>
> --
> viresh
Any progress on this?
Did we reach on agreement with s/@/-/ ?
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH V2 2/2] thermal: broadcom: add Northstar thermal driver
From: Eduardo Valentin @ 2017-03-31 3:15 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Zhang Rui, Rob Herring, Mark Rutland, Stephen Warren, Lee Jones,
Eric Anholt, Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Rafał Miłecki, Jon Mason
In-Reply-To: <20170323223045.15786-2-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello,
On Thu, Mar 23, 2017 at 11:30:45PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Northstar is a SoC family commonly used in home routers. This commit
> adds a driver for checking CPU temperature. As Northstar Plus seems to
> also have this IP block this new symbol gets ARCH_BCM_IPROC dependency.
>
Can you please educate me on how different this driver is from
https://patchwork.kernel.org/patch/9619579/
?
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> V2: Make it iProc specific as NSP can also use this driver
> Select proper symbols in config ARCH_BCM_IPROC
> Define PVTMON register bits
> Update code selecting temperature monitor mode
> Thank you Jon!
> ---
> arch/arm/mach-bcm/Kconfig | 2 +
> drivers/thermal/Kconfig | 5 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/broadcom/Kconfig | 7 +++
> drivers/thermal/broadcom/Makefile | 1 +
> drivers/thermal/broadcom/ns-thermal.c | 98 +++++++++++++++++++++++++++++++++++
Ok. This driver attempts to create a common place for broadcom thermal
drivers, which is good, but..
> 6 files changed, 114 insertions(+)
> create mode 100644 drivers/thermal/broadcom/Kconfig
> create mode 100644 drivers/thermal/broadcom/Makefile
> create mode 100644 drivers/thermal/broadcom/ns-thermal.c
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index a0e66d8200c5..da2bfeb8e390 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
> select GPIOLIB
> select ARM_AMBA
> select PINCTRL
> + select THERMAL
> + select THERMAL_OF
> help
> This enables support for systems based on Broadcom IPROC architected SoCs.
> The IPROC complex contains one or more ARM CPUs along with common
To avoid conflicts I would suggest getting this patch split into driver
and arch code changes.
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 776b34396144..008e173ec825 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -392,6 +392,11 @@ config MTK_THERMAL
> Enable this option if you want to have support for thermal management
> controller present in Mediatek SoCs
>
> +menu "Broadcom thermal drivers"
> +depends on ARCH_BCM || COMPILE_TEST
Does the above dependency also work for other BCM chips?
> +source "drivers/thermal/broadcom/Kconfig"
> +endmenu
> +
> menu "Texas Instruments thermal drivers"
> depends on ARCH_HAS_BANDGAP || COMPILE_TEST
> depends on HAS_IOMEM
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 7adae2029355..549d81b6363c 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -27,6 +27,7 @@ thermal_sys-$(CONFIG_CLOCK_THERMAL) += clock_cooling.o
> thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>
> # platform thermal drivers
> +obj-y += broadcom/
> obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
> new file mode 100644
> index 000000000000..39b92a1f3584
> --- /dev/null
> +++ b/drivers/thermal/broadcom/Kconfig
> @@ -0,0 +1,7 @@
> +config BCM_NS_THERMAL
> + tristate "Northstar thermal driver"
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + help
> + Northstar's DMU (Device Management Unit) block contains a thermal
> + sensor that allows checking CPU temperature. This driver provides
> + support for it.
It would be good if you could include a list of socs that have DMUs.
> diff --git a/drivers/thermal/broadcom/Makefile b/drivers/thermal/broadcom/Makefile
> new file mode 100644
> index 000000000000..059df9a0ed69
> --- /dev/null
> +++ b/drivers/thermal/broadcom/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_BCM_NS_THERMAL) += ns-thermal.o
> diff --git a/drivers/thermal/broadcom/ns-thermal.c b/drivers/thermal/broadcom/ns-thermal.c
> new file mode 100644
> index 000000000000..acf3a4de62a4
> --- /dev/null
> +++ b/drivers/thermal/broadcom/ns-thermal.c
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (C) 2017 Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define PVTMON_CONTROL0 0x00
> +#define PVTMON_CONTROL0_SEL_MASK 0x0000000e
> +#define PVTMON_CONTROL0_SEL_TEMP_MONITOR 0x00000000
> +#define PVTMON_CONTROL0_SEL_TEST_MODE 0x0000000e
> +#define PVTMON_STATUS 0x08
> +
> +struct ns_thermal {
> + void __iomem *pvtmon;
> +};
> +
> +static int ns_thermal_get_temp(void *data, int *temp)
> +{
> + struct ns_thermal *ns_thermal = data;
> + u32 val;
> +
> + val = readl(ns_thermal->pvtmon + PVTMON_CONTROL0);
> + if ((val & PVTMON_CONTROL0_SEL_MASK) != PVTMON_CONTROL0_SEL_TEMP_MONITOR) {
> + val &= ~PVTMON_CONTROL0_SEL_MASK;
> + val |= PVTMON_CONTROL0_SEL_TEMP_MONITOR;
> + writel(val, ns_thermal->pvtmon + PVTMON_CONTROL0);
> + }
> +
> + val = readl(ns_thermal->pvtmon + PVTMON_STATUS);
> + *temp = (418 - (val * 5556 / 10000)) * 1000;
> +
Could you move the above equation to DT? The other BCM driver I posted
the link above just went through the same process.
> + return 0;
> +}
> +
> +const struct thermal_zone_of_device_ops ns_thermal_ops = {
> + .get_temp = ns_thermal_get_temp,
> +};
> +
> +static int ns_thermal_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct ns_thermal *ns_thermal;
> + struct thermal_zone_device *tzd;
> +
> + ns_thermal = devm_kzalloc(dev, sizeof(*ns_thermal), GFP_KERNEL);
> + if (!ns_thermal)
> + return -ENOMEM;
> +
> + ns_thermal->pvtmon = of_iomap(dev_of_node(dev), 0);
> + if (WARN_ON(!ns_thermal->pvtmon))
> + return -ENOENT;
> +
> + tzd = devm_thermal_zone_of_sensor_register(dev, 0, ns_thermal,
> + &ns_thermal_ops);
> + if (IS_ERR(tzd)) {
> + iounmap(ns_thermal->pvtmon);
> + return PTR_ERR(tzd);
> + }
> +
> + platform_set_drvdata(pdev, ns_thermal);
> +
> + return 0;
> +}
> +
> +static int ns_thermal_remove(struct platform_device *pdev)
> +{
> + struct ns_thermal *ns_thermal = platform_get_drvdata(pdev);
> +
> + iounmap(ns_thermal->pvtmon);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ns_thermal_of_match[] = {
> + { .compatible = "brcm,ns-thermal", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ns_thermal_of_match);
> +
> +static struct platform_driver ns_thermal_driver = {
> + .probe = ns_thermal_probe,
> + .remove = ns_thermal_remove,
> + .driver = {
> + .name = "ns-thermal",
> + .of_match_table = ns_thermal_of_match,
> + },
> +};
> +module_platform_driver(ns_thermal_driver);
> +
> +MODULE_DESCRIPTION("Northstar thermal driver");
> +MODULE_LICENSE("GPL v2");
> --
> 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 V2 1/2] dt-bindings: thermal: add support for Broadcom's Northstar thermal
From: Eduardo Valentin @ 2017-03-31 3:17 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Zhang Rui, Rob Herring, Mark Rutland, Stephen Warren, Lee Jones,
Eric Anholt, Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, linux-pm, devicetree, linux-rpi-kernel,
linux-arm-kernel, Rafał Miłecki
In-Reply-To: <20170323223045.15786-1-zajec5@gmail.com>
Hello Rafal,
On Thu, Mar 23, 2017 at 11:30:44PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This commit documents binding for thermal used in Northstar family SoCs.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> .../devicetree/bindings/thermal/brcm,ns-thermal | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>
> diff --git a/Documentation/devicetree/bindings/thermal/brcm,ns-thermal b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
> new file mode 100644
> index 000000000000..9a22dd76ec01
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
> @@ -0,0 +1,17 @@
> +* Broadcom Northstar Thermal
> +
> +This binding describes thermal sensor that is part of Northstar's DMU (Device
> +Management Unit).
> +
> +Required properties:
> +- compatible : Must be "brcm,ns-thermal"
> +- reg : iomem address range of PVTMON registers
> +- #thermal-sensor-cells : Should be <0>
> +
> +Example:
> +
> +thermal {
> + compatible = "brcm,ns-thermal";
> + reg = <0x1800c2c0 0x10>;
> + #thermal-sensor-cells = <0>;
> +};
Could you please also include an example of the thermal zone one should
include in the board/cpu DTS while using this sensor?
Besides, based on what I saw you in your driver, you could also describe
your offset and slope in DT, and read them using thermal helpers.
BR,
> --
> 2.11.0
>
^ permalink raw reply
* Re: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations
From: Michael Ellerman @ 2017-03-31 3:27 UTC (permalink / raw)
To: Robin Murphy, roy.pledge-3arQi8VN3Tc, oss-fOR+EgIDQEHk1uMJSBkQmQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: madalin.bucur-3arQi8VN3Tc
In-Reply-To: <b1cd8d44-8c74-ab50-5dc9-1f978cae5bdf-5wv7dgnIgG8@public.gmane.org>
Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> writes:
> Hi Roy,
>
> On 29/03/17 22:13, Roy Pledge wrote:
>> Use the shared-memory-pool mechanism for frame queue descriptor and
>> packed frame descriptor record area allocations.
>
> Thanks for persevering with this - in my opinion it's now looking like
> it was worth the effort :)
>
> AFAICS the ioremap_wc() that this leads to does appear to give back
> something non-cacheable on PPC (assuming "pgprot_noncached_wc" isn't
> horrendously misnamed), and "no-map" should rule out any cacheable
> linear map alias existing, so it would seem that this approach should
> avert Scott's concerns about attribute mismatches.
How does 'no-map' translate into something being excluded from the
linear mapping?
cheers
--
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 v3 00/37] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
From: Masahiro Yamada @ 2017-03-31 4:05 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-mtd, Enrico Jorns, Artem Bityutskiy, Dinh Nguyen,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, devicetree, Linux Kernel Mailing List,
Brian Norris, Richard Weinberger, Cyrille Pitchen, Rob Herring,
Mark Rutland
In-Reply-To: <20170330183805.1c29504f@bbrezillon>
Hi Boris,
2017-03-31 1:38 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
> The rest looks almost good, except for a few comments I had on patch
> 14, 18, 25, 26 and 32.
>
> I'll probably apply 33 and 34 soon.
>
Thank you!
Please note I left a minor comment on 34.
(Accidental addition of braces.)
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] arm64: dts: uniphier: add input-delay properties to Cadence eMMC node
From: Masahiro Yamada @ 2017-03-31 4:20 UTC (permalink / raw)
To: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Piotr Sroka, Masahiro Yamada, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Will Deacon,
Mark Rutland, Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Since commit a04e2b383401 ("mmc: sdhci-cadence: Update PHY delay
configuration"), PHY parameters must be specified by DT.
The hard-coded settings have been converted as follows:
- SDHCI_CDNS_PHY_DLY_SD_DEFAULT -> cdns,phy-input-delay-legacy
- SDHCI_CDNS_PHY_DLY_EMMC_SDR -> cdns,phy-input-delay-mmc-highspeed
- SDHCI_CDNS_PHY_DLY_EMMC_DDR -> cdns,phy-input-delay-mmc-ddr
The following have not been moved:
- SDHCI_CDNS_PHY_DLY_SD_HS
this is unneeded in the eMMC configuration
- SDHCI_CDNS_PHY_DLY_EMMC_LEGACY
this is never enabled by the driver as it is covered by
SDHCI_CDNS_PHY_DLY_SD_DEFAULT
Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
---
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 3 +++
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 5dc5124..b6ebdc9 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -310,6 +310,9 @@
bus-width = <8>;
mmc-ddr-1_8v;
mmc-hs200-1_8v;
+ cdns,phy-input-delay-legacy = <4>;
+ cdns,phy-input-delay-mmc-highspeed = <2>;
+ cdns,phy-input-delay-mmc-ddr = <3>;
};
usb0: usb@5a800100 {
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 6c9a72d..0ab6c2e 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -394,6 +394,9 @@
bus-width = <8>;
mmc-ddr-1_8v;
mmc-hs200-1_8v;
+ cdns,phy-input-delay-legacy = <4>;
+ cdns,phy-input-delay-mmc-highspeed = <2>;
+ cdns,phy-input-delay-mmc-ddr = <3>;
};
sd: sdhc@5a400000 {
--
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: [PATCH 2/2] dt-bindings: mtd: document linux,part-probe property
From: Rafał Miłecki @ 2017-03-31 5:03 UTC (permalink / raw)
To: Marek Vasut, David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <74e3a663-2431-9b86-9d90-7f2fe6ce900f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 03/31/2017 01:26 AM, Marek Vasut wrote:
> On 03/30/2017 11:53 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>
>> Support for this property has been introduced in 2010 with commit
>> 9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
>> parition probe") but it was never documented. Fix this by adding a
>> proper description and example.
>>
>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
>> index fc068b923d7a..1ada70e718b2 100644
>> --- a/Documentation/devicetree/bindings/mtd/common.txt
>> +++ b/Documentation/devicetree/bindings/mtd/common.txt
>> @@ -6,10 +6,17 @@ Optional properties:
>> controller based name) in order to ease flash device identification
>> and/or describe what they are used for.
>>
>> +- linux,part-probe: if present, this property should contain a list of strings
>> + with partition probes to be used for the flash device. A role of partition
>> + probe (parser) is to read/construct partition table and register found
>> + partitions. Getting partition table may be platform or device specific so
>> + various devices may use various Linux drivers for this purpose.
>
> Why don't you just have partition not within partition node ? Then you
> won't need this nonsense ...
Can you stop this negative approach ("nonsense") for every single f* thing I
submit? It doesn't help and makes people not want to work with upstream mtd.
The only partitioner with support for partitions node is "fixed-partitions".
Take a look at original linux,part-probe usage:
arch/arm64/boot/dts/arm/juno-motherboard.dtsi
It's used to specify "afs" partitioner. It's dynamic. You can't replace it with
fixed partitions.
So this property is needed to specify platform/device specific partitioner that
should be used with some standard flash driver (like physmap_of or m25p80).
I was hoping following part of documentation makes is clear:
> Getting partition table may be platform or device specific so
> various devices may use various Linux drivers for this purpose.
--
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 v3 14/37] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Masahiro Yamada @ 2017-03-31 5:06 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-mtd, Enrico Jorns, Artem Bityutskiy, Dinh Nguyen,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, devicetree, Linux Kernel Mailing List,
Brian Norris, Richard Weinberger, Cyrille Pitchen, Rob Herring,
Mark Rutland
In-Reply-To: <20170330160238.59e5a2c1@bbrezillon>
Hi Boris,
2017-03-30 23:02 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
> On Thu, 30 Mar 2017 15:46:00 +0900
> Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>
>> Historically, this driver tried to choose as big ECC strength as
>> possible, but it would be reasonable to allow DT to set a particular
>> ECC strength with "nand-ecc-strength" property. This is useful
>> when a particular ECC setting is hard-coded by firmware (or hard-
>> wired by boot ROM).
>>
>> If no ECC strength is specified in DT, "nand-ecc-maximize" is implied
>> since this was the original behavior.
>
> You said there is currently no DT users,
Right. No DT users ever in upstream.
> so how about changing the
> "fallback to ECC maximization" behavior for DT users, and instead of
> maximizing the ECC strength take the NAND requirements into account
> (chip->ecc_strength_ds).
This is difficult to judge in some cases.
As I said before, 4/512 and 8/1024 are not equivalent.
If chip's requirement chip->ecc_step_ds matches
to the ecc->size supported by the controller,
this is easy.
If a chip requests 1024B, then the controller can only support 512B chunk
(or vice versa), it is difficult to simply compare
ecc strength.
Is it a bad thing if we use too strong ECC strength?
The disadvantage I see is we will have less OOB-free bytes,
but this will not be fatal, I guess.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] Documentation: dt: Add binding for /secure-chosen/stdout-path
From: Jerome Forissier @ 2017-03-31 6:34 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
jens.wiklander-QSEj5FYQhm4dnm+yROfE0A,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A,
peter.maydell-QSEj5FYQhm4dnm+yROfE0A, robin.murphy-5wv7dgnIgG8
In-Reply-To: <20170330222845.ewddsnmkxwrsposl@rob-hp-laptop>
On 03/31/2017 12:28 AM, Rob Herring wrote:
> On Fri, Mar 03, 2017 at 10:24:33AM +0100, Jerome Forissier wrote:
>> Some platforms may use a single device tree to describe two address
>> spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
>> for Secure-only devices"). For these platforms it makes sense to define
>> a secure counterpart of /chosen, namely: /secure-chosen. This new node
>> is meant to be used by the secure firmware to pass data to the secure
>> OS. Only the stdout-path property is supported for now.
>>
>> Signed-off-by: Jerome Forissier <jerome.forissier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/arm/secure.txt | 19 ++++++++++++++++++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> v2
>>
>> - Clarify the expected behavior when /secure-chosen/stdout-path is not
>> present (either the property or the node itself), as proposed by Peter
>> and Robin. Note that I have made the fallback to /chosen optional.
>
> I'm okay with this, but would like to hold off merging it until your are
> really using it. You did say you were "experimenting" and it doesn't
> sound like the DT usage in secure world is that far along. I just want
> to see if there are other issues that come up.
Fair enough.
Thanks,
--
Jerome
--
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