* Re: [PATCH 1/2] drm/bridge: ti-tfp410: support hpd via gpio
From: Christopher Spinrath @ 2017-03-30 21:51 UTC (permalink / raw)
To: Archit Taneja, Jyri Sarha
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Airlie, Fabio Estevam, Russell King - ARM Linux,
DRI mailing list, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Igor Grinberg, Sascha Hauer, Fabio Estevam, Shawn Guo,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <e63e628794b044c2a615091697622d50-cBaz+nnMw18umhiu9RXYRl5UTUQ924AY@public.gmane.org>
Hi,
On 03/30/2017 11:49 AM, Archit Taneja wrote:
>
>
> On 03/28/2017 07:02 PM, Jyri Sarha wrote:
>> On 03/27/17 08:58, Archit Taneja wrote:
>>> Hi,
>>>
>>> On 03/07/2017 03:21 AM, Christopher Spinrath wrote:
>>>> Hi Fabio,
>>>>
>>>> On 03/06/2017 10:46 PM, Fabio Estevam wrote:
>>>>> Hi Christopher,
>>>>>
>>>>> On Mon, Mar 6, 2017 at 6:40 PM,
>>>>> <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org> wrote:
>>>>>> From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>>>>>>
>>>>>> On some boards the hpd pin of a hdmi connector is wired up to a gpio
>>>>>> pin. Since in the DRM world the tfp410 driver is responsible for
>>>>>> handling the connector, add support for hpd gpios in this very
>>>>>> driver.
>>>>>>
>>>>>> Signed-off-by: Christopher Spinrath
>>>>>> <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>>>>>> ---
>>>>>> drivers/gpu/drm/bridge/ti-tfp410.c | 72
>>>>>> ++++++++++++++++++++++++++++++++++++--
>>>>>
>> ...
>>>>
>>>
>>> The patch looks good to me.
>>>
>>> Jyri,
>>>
>>> Is it possible for you to verify this on Beaglebone platform?
>>>
>>
>> If I read my BeagleBone DVI-D Cape docs right, it does not have the HPD
>> pin connected. At least it does not mention any gpio that could be used
>> for the purpose. So I can not easily test this patch in real world
>> situation. For what it is worth the patch looks ok to me too.
>
> Thanks for the review. I looked at the tfp410 data sheet[1], there isn't
> a HPD pin on the chip at all. My guess is that boards using tfp410 most
> likely have the HPD pin routed to the SoC from the HDMI connector
> (with a level shifter/shield in between).
Exactly. I tried to say that in the commit message (and, actually,
that's what I did in Patch 2/2 for the Utilite Pro).
Thanks,
Christopher
> We would eventually need to move the both ddc and hpd stuff to
> a generic hdmi connector driver later on. I've queued this to
> drm-misc-next.
>
> [1]: http://www.ti.com/lit/ds/symlink/tfp410.pdf
>
> Archit
>
>>
>> Best regards,
>> Jyri
>>
>>
>> _______________________________________________
>> 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 V8 0/7] LPC: legacy ISA I/O support
From: dann frazier @ 2017-03-30 21:42 UTC (permalink / raw)
To: zhichang.yuan
Cc: Catalin Marinas, Will Deacon, Rob Herring, Frank Rowand,
Bjorn Helgaas, rafael, Arnd Bergmann, linux-arm-kernel,
Mark Rutland, devicetree@vger.kernel.org, lorenzo.pieralisi,
Gabriele Paoloni, Corey Minyard, benh, John Garry,
linux-kernel@vger.kernel.org, xuwei5, linuxarm, linux-acpi,
Zou Rongrong, linux-pci, olof
In-Reply-To: <1490887619-61732-1-git-send-email-yuanzhichang@hisilicon.com>
On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
<yuanzhichang@hisilicon.com> wrote:
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.
> -----------
> | LPC host|
> | |
> -----------
> |
> _____________V_______________LPC
> | |
> V V
> ------------
> | BT(ipmi)|
> ------------
>
> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific
> LPC driver is needed to make LPC host generate the standard LPC I/O cycles with
> the target peripherals'I/O port addresses. But on curent arm64 world, there is
> no real I/O accesses. All the I/O operations through in/out pair are based on
> MMIO which is not satisfied the I/O mechanism on Hip06/Hip07 LPC.
> To solve this issue and keep the relevant existing peripherals' driver
> untouched, this patchset implements:
> - introduces a generic I/O space management framwork, LIBIO, to support I/O
> operations of both MMIO buses and the host controllers which access their
> peripherals with host local I/O addresses;
> - redefines the in/out accessors to provide unified interfaces for MMIO and
> legacy I/O. Based on the LIBIO, the calling of in/out() from upper-layer
> drivers, such as ipmi-si, will be redirected to the corresponding
> device-specific I/O hooks to perfrom the I/O accesses.
> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals can
> be supported without any changes on the existing ipmi-si driver.
>
> Changes from V7:
> - Based on Arnd's comment, rename the LIBIO as LOGIC_PIO;
> - Improved the mapping process in LOGIC_PIO to gain better efficiency when
> redirecting the I/O accesses to right device driver;
> - To reduce the impact on PCI MMIO to a minimum, add a new
> CONFIG_INDIRECT_PIO for indirect-IO hosts/devices;
> - Added a new ACPI handler for indirect-IO hosts/devices;
> - Fixed the compile issues on V6;
>
> Changes from V6:
> - According to the comments from Bjorn and Alex, merge PCI IO and indirect-IO
> into a generic I/O space management, LIBIO;
> - Adopted the '_DEP' to replace the platform bus notifier. In this way, we can
> ensure the LPC peripherals' I/O resources had been translated to logical IO
> before the LPC peripheral enumeration;
> - Replaced the rwlock with rcu list based on Alex's suggestion;
> - Applied relaxed write/read to LPC driver;
> - Some bugs fixing and some optimazations based on the comments of V6;
>
> Changes from V5:
> - Made the extio driver more generic and locate in lib/;
> - Supported multiple indirect-IO bus instances;
> - Extended the pci_register_io_range() to support indirect-IO, then dropped
> the I/O reservation used in previous patchset;
> - Reimplemented the ACPI LPC support;
> - Fixed some bugs, including the compile error on other archs, the module
> building failure found by Ming Lei, etc;
>
> Changes from V4:
> - Some revises based on the comments from Bjorn, Rob on V4;
> - Fixed the compile error on some platforms, such as openrisc;
>
> Changes from V3:
> - UART support deferred to a separate patchset; This patchset only support
> ipmi device under LPC;
> - LPC bus I/O range is fixed to 0 ~ (PCIBIOS_MIN_IO - 1), which is separeted
> from PCI/PCIE PIO space;
> - Based on Arnd's remarks, removed the ranges property from Hip06 lpc dts and
> added a new fixup function, of_isa_indirect_io(), to get the I/O address
> directly from LPC dts configurations;
> - Support in(w,l)/out(w,l) for Hip06 lpc I/O;
> - Decouple the header file dependency on the gerenic io.h by defining in/out
> as normal functions in c file;
> - removed unused macro definitions in the LPC driver;
>
> Changes from V2:
> - Support the PIO retrieval from the linux PIO generated by
> pci_address_to_pio. This method replace the 4K PIO reservation in V2;
> - Support the flat-tree earlycon;
> - Some revises based on Arnd's remarks;
> - Make sure the linux PIO range allocated to Hip06 LPC peripherals starts
> from non-ZERO;
>
> Changes from V1:
> - Support the ACPI LPC device;
> - Optimize the dts LPC driver in ISA compatible mode;
> - Reserve the IO range below 4K in avoid the possible conflict with PCI host
> IO ranges;
> - Support the LPC uart and relevant earlycon;
>
> V7 thread here: https://lkml.org/lkml/2017/3/12/279
> v6 thread here: https://lkml.org/lkml/2017/1/24/25
> v5 thread here: https://lkml.org/lkml/2016/11/7/955
> v4 thread here: https://lkml.org/lkml/2016/10/20/149
> v3 thread here: https://lkml.org/lkml/2016/9/14/326
> v2 thread here: https://lkml.org/lkml/2016/9/7/356
> v1 thread here: https://lkml.org/lkml/2015/12/29/154
>
>
> Signed-off-by: Zhichang Yuan <yuanzhichang@hisilicon.com>
> zhichang.yuan (6):
> LIBIO: Introduce a generic PIO mapping method
> PCI: Apply the new generic I/O management on PCI IO hosts
> OF: Add missing I/O range exception for indirect-IO devices
> LPC: Support the device-tree LPC host on Hip06/Hip07
> ACPI: Support the probing on the devices which apply indirect-IO
> LPC: Add the ACPI LPC support
>
> .../arm/hisilicon/hisilicon-low-pin-count.txt | 33 ++
> MAINTAINERS | 8 +
> arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 4 +
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 14 +
> arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 4 +
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 14 +
> drivers/acpi/Makefile | 1 +
> drivers/acpi/acpi_indirectio.c | 344 +++++++++++++
> drivers/acpi/internal.h | 5 +
> drivers/acpi/pci_root.c | 8 +-
> drivers/acpi/scan.c | 1 +
> drivers/bus/Kconfig | 9 +
> drivers/bus/Makefile | 1 +
> drivers/bus/hisi_lpc.c | 547 +++++++++++++++++++++
> drivers/of/address.c | 95 +++-
> drivers/pci/pci.c | 104 +---
> include/asm-generic/io.h | 50 ++
> include/linux/logic_pio.h | 174 +++++++
> include/linux/pci.h | 3 +-
> lib/Kconfig | 26 +
> lib/Makefile | 2 +
> lib/logic_pio.c | 413 ++++++++++++++++
> 22 files changed, 1758 insertions(+), 102 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
> create mode 100644 drivers/acpi/acpi_indirectio.c
> create mode 100644 drivers/bus/hisi_lpc.c
> create mode 100644 include/linux/logic_pio.h
> create mode 100644 lib/logic_pio.c
Booted up on a D05, was able to use the LPC-connected IPMI interface.
Tested-by: dann frazier <dann.frazier@canonical.com>
^ permalink raw reply
* Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master (fwd)
From: Julia Lawall @ 2017-03-30 21:39 UTC (permalink / raw)
To: Christopher Bostic
Cc: joel-U3u1mxZcP9KHXe+LvDLADg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew-zrmu5oMJ5Fs, alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, Edward A . James,
Jeremy Kerr, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kbuild-all-JC7UmRfGjtg
Is master on line 514 allocated with kmalloc, or the devm call on line
522?
julia
---------- Forwarded message ----------
Date: Fri, 31 Mar 2017 00:15:09 +0800
From: kbuild test robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: kbuild-JC7UmRfGjtg@public.gmane.org
Cc: Julia Lawall <julia.lawall-L2FTfq7BK8M@public.gmane.org>
Subject: Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
Hi Chris,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc4 next-20170330]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Christopher-Bostic/FSI-device-driver-implementation/20170330-184914
:::::: branch date: 5 hours ago
:::::: commit date: 5 hours ago
>> drivers/fsi/fsi-master-gpio.c:514:1-6: WARNING: invalid free of devm_ allocated data
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout f4bd3b6a41c7a59e9ce2e65947a4d3dfc2ee4a29
vim +514 drivers/fsi/fsi-master-gpio.c
f4bd3b6a Chris Bostic 2017-03-29 498 {
f4bd3b6a Chris Bostic 2017-03-29 499 struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
f4bd3b6a Chris Bostic 2017-03-29 500
f4bd3b6a Chris Bostic 2017-03-29 501 if (link != 0)
f4bd3b6a Chris Bostic 2017-03-29 502 return -ENODEV;
f4bd3b6a Chris Bostic 2017-03-29 503 if (master->gpio_enable)
f4bd3b6a Chris Bostic 2017-03-29 504 gpiod_set_value(master->gpio_enable, 1);
f4bd3b6a Chris Bostic 2017-03-29 505
f4bd3b6a Chris Bostic 2017-03-29 506 return 0;
f4bd3b6a Chris Bostic 2017-03-29 507 }
f4bd3b6a Chris Bostic 2017-03-29 508
f4bd3b6a Chris Bostic 2017-03-29 509 static void fsi_master_gpio_release(struct device *dev)
f4bd3b6a Chris Bostic 2017-03-29 510 {
f4bd3b6a Chris Bostic 2017-03-29 511 struct fsi_master_gpio *master = to_fsi_master_gpio(
f4bd3b6a Chris Bostic 2017-03-29 512 dev_to_fsi_master(dev));
f4bd3b6a Chris Bostic 2017-03-29 513
f4bd3b6a Chris Bostic 2017-03-29 @514 kfree(master);
f4bd3b6a Chris Bostic 2017-03-29 515 }
f4bd3b6a Chris Bostic 2017-03-29 516
f4bd3b6a Chris Bostic 2017-03-29 517 static int fsi_master_gpio_probe(struct platform_device *pdev)
f4bd3b6a Chris Bostic 2017-03-29 518 {
f4bd3b6a Chris Bostic 2017-03-29 519 struct fsi_master_gpio *master;
f4bd3b6a Chris Bostic 2017-03-29 520 struct gpio_desc *gpio;
f4bd3b6a Chris Bostic 2017-03-29 521
f4bd3b6a Chris Bostic 2017-03-29 522 master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
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: [PATCHv5 06/11] s5p-cec.txt: document the HDMI controller phandle
From: Krzysztof Kozlowski @ 2017-03-30 21:37 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, Daniel Vetter, Russell King, dri-devel,
linux-samsung-soc, Inki Dae, Marek Szyprowski,
Javier Martinez Canillas, Benjamin Gaignard, Hans Verkuil,
devicetree
In-Reply-To: <20170329141543.32935-7-hverkuil@xs4all.nl>
On Wed, Mar 29, 2017 at 04:15:38PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Update the bindings documenting the new hdmi phandle.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> CC: linux-samsung-soc@vger.kernel.org
> CC: devicetree@vger.kernel.org
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCHv5 05/11] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
From: Krzysztof Kozlowski @ 2017-03-30 21:34 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, Daniel Vetter, Russell King, dri-devel,
linux-samsung-soc, Inki Dae, Marek Szyprowski,
Javier Martinez Canillas, Benjamin Gaignard, Hans Verkuil,
devicetree
In-Reply-To: <20170329141543.32935-6-hverkuil@xs4all.nl>
On Wed, Mar 29, 2017 at 04:15:37PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the
> s5p-cec driver to initialize the CEC notifier framework.
>
> Tested with my Odroid U3.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> CC: linux-samsung-soc@vger.kernel.org
> CC: devicetree@vger.kernel.org
> CC: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm/boot/dts/exynos4.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
Thanks, applied. Now I noticed that you need it for maintaining the
bisectability for this driver (although it is a staging driver). In that
case, if anyone needs this as well then:
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-hdmi-cec-4.12
for you to fetch changes up to 192c1df4a75499a6ab70aca38c6a7e5e40013d77:
ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi (2017-03-31 00:21:18 +0300)
----------------------------------------------------------------
Add to hdmi-cec node a phandle to hdmi node for new hdmi-cec notifier.
----------------------------------------------------------------
Hans Verkuil (1):
ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
arch/arm/boot/dts/exynos4.dtsi | 1 +
1 file changed, 1 insertion(+)
Best regards,
Krzysztof
^ permalink raw reply
* Applied "regulator: arizona-micsupp: Avoid potential memory leak reading init_data" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
The patch
regulator: arizona-micsupp: Avoid potential memory leak reading init_data
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 2543ef3173889373fc07df61520e1bb42a99c85e Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Tue, 28 Mar 2017 15:14:37 +0100
Subject: [PATCH] regulator: arizona-micsupp: Avoid potential memory leak
reading init_data
The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.
Correct this issue by correctly passing the local platform device.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-micsupp.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c b/drivers/regulator/arizona-micsupp.c
index fcb98dbda837..0ed14e41de11 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -197,7 +197,8 @@ static const struct regulator_init_data arizona_micsupp_ext_default = {
.num_consumer_supplies = 1,
};
-static int arizona_micsupp_of_get_pdata(struct arizona *arizona,
+static int arizona_micsupp_of_get_pdata(struct device *dev,
+ struct arizona *arizona,
struct regulator_config *config,
const struct regulator_desc *desc)
{
@@ -211,7 +212,7 @@ static int arizona_micsupp_of_get_pdata(struct arizona *arizona,
if (np) {
config->of_node = np;
- init_data = of_get_regulator_init_data(arizona->dev, np, desc);
+ init_data = of_get_regulator_init_data(dev, np, desc);
if (init_data) {
init_data->consumer_supplies = &micsupp->supply;
@@ -266,8 +267,8 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_micsupp_of_get_pdata(arizona, &config,
- desc);
+ ret = arizona_micsupp_of_get_pdata(&pdev->dev, arizona,
+ &config, desc);
if (ret < 0)
return ret;
}
--
2.11.0
^ permalink raw reply related
* Applied "regulator: arizona-ldo1: Avoid potential memory leak reading init_data" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-2-git-send-email-ckeepax@opensource.wolfsonmicro.com>
The patch
regulator: arizona-ldo1: Avoid potential memory leak reading init_data
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0feb837a42c95fee901e03f76a1266db85ceb6ec Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Tue, 28 Mar 2017 15:14:38 +0100
Subject: [PATCH] regulator: arizona-ldo1: Avoid potential memory leak reading
init_data
The device argument passed to of_get_regulator_init_data is used to
do some devres memory allocation. Currently the driver passes the MFD
device pointer to this function, this could result in the init_data
allocation being leaked if the regulator is unbound but the MFD isn't.
Correct this issue by correctly passing the local platform device.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/arizona-ldo1.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index 302b57cb89c6..cf558168664d 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -186,7 +186,8 @@ static const struct regulator_init_data arizona_ldo1_wm5110 = {
.num_consumer_supplies = 1,
};
-static int arizona_ldo1_of_get_pdata(struct arizona *arizona,
+static int arizona_ldo1_of_get_pdata(struct device *dev,
+ struct arizona *arizona,
struct regulator_config *config,
const struct regulator_desc *desc)
{
@@ -212,8 +213,7 @@ static int arizona_ldo1_of_get_pdata(struct arizona *arizona,
if (init_node) {
config->of_node = init_node;
- init_data = of_get_regulator_init_data(arizona->dev, init_node,
- desc);
+ init_data = of_get_regulator_init_data(dev, init_node, desc);
if (init_data) {
init_data->consumer_supplies = &ldo1->supply;
@@ -283,7 +283,8 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_ldo1_of_get_pdata(arizona, &config, desc);
+ ret = arizona_ldo1_of_get_pdata(&pdev->dev, arizona,
+ &config, desc);
if (ret < 0)
return ret;
}
--
2.11.0
^ permalink raw reply related
* Applied "MAINTAINERS: Add missing regulator regex for Wolfson Arizona parts" to the regulator tree
From: Mark Brown @ 2017-03-30 21:23 UTC (permalink / raw)
To: Charles Keepax; +Cc: Mark Brown
In-Reply-To: <1490710484-25277-3-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
The patch
MAINTAINERS: Add missing regulator regex for Wolfson Arizona parts
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From cdf4275e957c6bad3756e98942341667f1d7de7d Mon Sep 17 00:00:00 2001
From: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Date: Tue, 28 Mar 2017 15:14:39 +0100
Subject: [PATCH] MAINTAINERS: Add missing regulator regex for Wolfson Arizona
parts
The maintainers entry for the Wolfson parts seems to be missing
an entry that covers the Arizona regulator drivers, correct this by
adding one.
Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9bf5aa617cf2..ef0c801aff45 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13119,6 +13119,7 @@ F: drivers/mfd/cs47l24*
F: drivers/power/supply/wm83*.c
F: drivers/rtc/rtc-wm83*.c
F: drivers/regulator/wm8*.c
+F: drivers/regulator/arizona*
F: drivers/video/backlight/wm83*_bl.c
F: drivers/watchdog/wm83*_wdt.c
F: include/linux/mfd/arizona/
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM: dts: r7s72100: fix ethernet clock parent
From: Chris Brandt @ 2017-03-30 21:16 UTC (permalink / raw)
To: Simon Horman, Rob Herring, Mark Rutland, Geert Uytterhoeven
Cc: devicetree, linux-renesas-soc, Chris Brandt
Technically, the Ethernet block is run off the 133MHz Bus (B) clock, not
the 33MHz Peripheral 0 (P0) clock.
Fixes: 969244f9c720 ("ARM: dts: r7s72100: add ethernet clock to device tree")
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
arch/arm/boot/dts/r7s72100.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 34994afa9d15..c199c4eea73e 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -121,7 +121,7 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0xfcfe0430 4>;
- clocks = <&p0_clk>;
+ clocks = <&b_clk>;
clock-indices = <R7S72100_CLK_ETHER>;
clock-output-names = "ether";
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
From: Benjamin Herrenschmidt @ 2017-03-30 20:50 UTC (permalink / raw)
To: Christopher Bostic, Joel Stanley
Cc: Mark Rutland, devicetree, Andrew Jeffery, Greg KH, Russell King,
rostedt, Linux Kernel Mailing List, Rob Herring, Jeremy Kerr,
Edward A . James, Alistair Popple, mingo, linux-arm-kernel
In-Reply-To: <0e1bcf3a-e8d7-9f50-bdf7-2a1e7466665b@linux.vnet.ibm.com>
On Thu, 2017-03-30 at 13:15 -0500, Christopher Bostic wrote:
> > > +static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg *msg,
> > > + uint8_t num_bits)
> > > +{
> > > + uint8_t bit, in_bit;
> > > +
> > > + set_sda_input(master);
> > > +
> > > + for (bit = 0; bit < num_bits; bit++) {
> > > + clock_toggle(master, 1);
> > > + in_bit = sda_in(master);
> > > + msg->msg <<= 1;
> > > + msg->msg |= ~in_bit & 0x1; /* Data is negative active */
> > > + }
> > > + msg->bits += num_bi ts;
> > > +}
> > > +
> > > +static void serial_out(struct fsi_master_gpio *master,
> > > + const struct fsi_gpio_msg *cmd)
> > > +{
> > > + uint8_t bit;
> > > + uint64_t msg = ~cmd->msg; /* Data is negative active */
> > > + uint64_t sda_mask = 0x1ULL << (cmd->bits - 1);
> > > + uint64_t last_bit = ~0;
> > > + int next_bit;
> > > +
> > > + if (!cmd->bits) {
> > > + dev_warn(master->dev, "trying to output 0 bits\n");
> > > + return;
> > > + }
> > > + set_sda_output(master, 0);
> > > +
> > > + /* Send the start bit */
> > > + sda_out(master, 0);
> > > + clock_toggle(master, 1);
> > > +
> > > + /* Send the message */
> > > + for (bit = 0; bit < cmd->bits; bit++) {
> > > + next_bit = (msg & sda_mask) >> (cmd->bits - 1);
> > > + if (last_bit ^ next_bit) {
> > > + sda_out(master, next_bit);
> > > + last_bit = next_bit;
> > > + }
> > > + clock_toggle(master, 1);
> > > + msg <<= 1;
> > > + }
> > > +}
As I mentioned privately, I don't think this is right, unless your
clock signal is inverted or my protocol spec is wrong...
Your clock toggle is written so you call it right after the rising
edge. It does delay, 0, delay, 1.
But according to the FSI timing diagram I have, you need to establish
the data around the falling edge, it gets sampled by the slave on the
rising edge. So as it is, your code risks violating the slave hold
time.
On input, you need to sample on the falling edge, right before it. You
are sampling after the rising edge, so you aren't leaving enough time
for the slave to establish the data.
You could probably just flip clock_toggle() around. Make it: 0, delay,
1, delay.
That way you can do for sends: sda_out + toggle, and for receive
toggle + sda_in. That will make you establish your output data and
sample right before the falling edge, which should be ok provided the
diagram I have is right.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO
From: Rafael J. Wysocki @ 2017-03-30 20:31 UTC (permalink / raw)
To: zhichang.yuan
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rafael-DgEjT+Ai2ygdnm+yROfE0A,
arnd-r2nGTMty4D4,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, brian.starkey-5wv7dgnIgG8,
olof-nZhT3qVonbNeoWH0uzbU5w, lorenzo.pieralisi-5wv7dgnIgG8,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q
In-Reply-To: <1490887619-61732-6-git-send-email-yuanzhichang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
On Thursday, March 30, 2017 11:26:58 PM zhichang.yuan wrote:
> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
> with some special host-local I/O ports known on x86. To access the I/O
> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
> registered before probing the downstream devices and set up the I/O mapping.
> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>
> This patch introdueces a new ACPI handler for this device category. Through the
> handler attach callback, the indirect-IO hosts I/O registration is done and
> all peripherals' I/O resources are translated into logic/fake PIO before
> starting the enumeration.
Can you explain to me briefly what exactly this code is expected to be doing?
Thanks,
Rafael
--
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] ASoC: wm8903: add regulator handling
From: Stephen Warren @ 2017-03-30 19:42 UTC (permalink / raw)
To: Linus Walleij, Liam Girdwood, Mark Brown
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Charles Keepax
In-Reply-To: <20170320091352.4115-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 03/20/2017 03:13 AM, Linus Walleij wrote:
> The WM8903 has four different voltage inputs: AVDD, CPVDD, DBVDD
> and DCVDD. On the Qualcomm APQ8060 Dragonboard these are all
> supplied from proper regulators and thus need activating and
> binding.
>
> This is a quick-and-dirty solution just grabbing and enabling the
> regulator supplies on probe() and disabling them on remove() and
> the errorpath. More elaborate power management is likely possible.
>
> I assume the nVidia designs using this codec have some hard-wired
> always-on power and will be happy with using the dummy regulators
> for this. But someone from the nVidia camp should probably check
> whether they can bind these to proper regulators instead.
>
> We also amend the DT binding document. A small change like this
> does not warrant a separate patch for augmenting these.
Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Sorry for the slow response.
Tested using NVIDIA springbank/seaboard board. Just in case anyone reads
this later and wonders how: I will point out that in the baseline
v4.11-rc4, the LCD (or perhaps just its backlight) doesn't work on this
HW any more, but since the GUI login prompt plays a sound, I was still
able to validate the WM8903 change.
--
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: [v5 2/4] dt-bindings: mmc: add description of PHY delays for sdhci-cadence
From: Ulf Hansson @ 2017-03-30 19:31 UTC (permalink / raw)
To: Piotr Sroka
Cc: linux-mmc@vger.kernel.org, Adrian Hunter,
linux-kernel@vger.kernel.org, Masahiro Yamada, Rob Herring,
Mark Rutland, devicetree@vger.kernel.org
In-Reply-To: <1490106781-3129-1-git-send-email-piotrs@cadence.com>
On 21 March 2017 at 15:33, Piotr Sroka <piotrs@cadence.com> wrote:
> DTS properties are used instead of fixed data
> because PHY settings can be different for different chips/boards.
> Add description of new DLL PHY delays.
>
> Signed-off-by: Piotr Sroka <piotrs@cadence.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> Changes for v2:
> - file was created in v2. It was a part of driver source file patch.
> - most delays were moved from dts file
> to data associated with an SoC specific compatible
> - description of delays was updated to be more clearly
> ---
> Changes for v3:
> - move all delays back to dts because they are also boards dependent
> - prefix all of the Cadence-specific properties with cdns prefix
> ---
> Changes for v4:
> - change the beginning of the commit subject
> ---
> Changes for v5:
> - change name of property to be consistent with timing modes
> available in Linux
> ---
> .../devicetree/bindings/mmc/sdhci-cadence.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> index c0f37cb..fa423c2 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> @@ -19,6 +19,53 @@ if supported. See mmc.txt for details.
> - mmc-hs400-1_8v
> - mmc-hs400-1_2v
>
> +Some PHY delays can be configured by following properties.
> +PHY DLL input delays:
> +They are used to delay the data valid window, and align the window
> +to sampling clock. The delay starts from 5ns (for delay parameter equal to 0)
> +and it is increased by 2.5ns in each step.
> +- cdns,phy-input-delay-sd-highspeed:
> + Value of the delay in the input path for SD high-speed timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-legacy:
> + Value of the delay in the input path for legacy timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-sd-uhs-sdr12:
> + Value of the delay in the input path for SD UHS SDR12 timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-sd-uhs-sdr25:
> + Value of the delay in the input path for SD UHS SDR25 timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-sd-uhs-sdr50:
> + Value of the delay in the input path for SD UHS SDR50 timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-sd-uhs-ddr50:
> + Value of the delay in the input path for SD UHS DDR50 timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-mmc-highspeed:
> + Value of the delay in the input path for MMC high-speed timing
> + Valid range = [0:0x1F].
> +- cdns,phy-input-delay-mmc-ddr:
> + Value of the delay in the input path for eMMC high-speed DDR timing
> + Valid range = [0:0x1F].
> +
> +PHY DLL clock delays:
> +Each delay property represents the fraction of the clock period.
> +The approximate delay value will be
> +(<delay property value>/128)*sdmclk_clock_period.
> +- cdns,phy-dll-delay-sdclk:
> + Value of the delay introduced on the sdclk output
> + for all modes except HS200, HS400 and HS400_ES.
> + Valid range = [0:0x7F].
> +- cdns,phy-dll-delay-sdclk-hsmmc:
> + Value of the delay introduced on the sdclk output
> + for HS200, HS400 and HS400_ES speed modes.
> + Valid range = [0:0x7F].
> +- cdns,phy-dll-delay-strobe:
> + Value of the delay introduced on the dat_strobe input
> + used in HS400 / HS400_ES speed modes.
> + Valid range = [0:0x7F].
> +
> Example:
> emmc: sdhci@5a000000 {
> compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
> @@ -29,4 +76,5 @@ Example:
> mmc-ddr-1_8v;
> mmc-hs200-1_8v;
> mmc-hs400-1_8v;
> + cdns,phy-dll-delay-sdclk = <0>;
> };
> --
> 2.2.2
>
^ permalink raw reply
* Re: [PATCH v3 0/6] bus: brcmstb_gisb: add support for GISBv7 arbiter
From: Florian Fainelli @ 2017-03-30 19:29 UTC (permalink / raw)
To: Mark Rutland, Florian Fainelli
Cc: Doug Berger, robh+dt, computersforpeace, gregory.0xf0,
bcm-kernel-feedback-list, linus.walleij, treding, jonathanh, olof,
mirza.krak, suzuki.poulose, bgolaszewski, devicetree,
linux-kernel, linux-arm-kernel, catalin.marinas, will.deacon
In-Reply-To: <20170330181932.GB8062@leverpostej>
On 03/30/2017 11:19 AM, Mark Rutland wrote:
> On Thu, Mar 30, 2017 at 09:33:32AM -0700, Florian Fainelli wrote:
>> On 03/29/2017 05:29 PM, Doug Berger wrote:
>>> This patch set contains changes to enable the GISB arbiter driver
>>> on the latest ARM64 architecture Set-Top Box chips from Broadcom.
>>>
>>> Since the ARM64 architecture does not support the hooking of low
>>> level fault handlers the driver has been adjusted to depend solely
>>> on GISB interrupts and notify events to provide diagnostic
>>> messaging. The GISB hardware still triggers bus faults for the
>>> processor so the default low-level aborts will occur and will be
>>> handled based on the architecture specific kernel implementation.
>>>
>>> While this tends to obsure the GISB error messaging it is still
>>> reasonable so the same approach is applied to the ARM architecture
>>> for consistency.
>>>
>>> The patches also correct some issues with the existing driver
>>> and add the new register map for the GISBv7 hardware first
>>> appearing in the BCM7278 device.
>>
>> This all looks great to me, and since there are no more ARM64
>> dependencies I can take this via the Broadcom ARM/ARM64 SoC pull requests.
>>
>> Mark, are you also happy with this v3?
>
> It looks fine by me.
Series applied to drivers/next, thanks everyone!
--
Florian
^ permalink raw reply
* Re: [PATCH V11 6/6] thermal: bcm2835: add thermal driver for bcm2835 SoC
From: Stefan Wahren @ 2017-03-30 19:11 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Frank Rowand, kernel, Eric Anholt, Zhang Rui, Rob Herring,
Florian Fainelli, linux-rpi-kernel, linux-pm, devicetree
In-Reply-To: <20170330045725.GA12995@localhost.localdomain>
Hi Eduardo,
> Eduardo Valentin <edubezval@gmail.com> 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@martin.sperl.org>
> > > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > > Acked-by: Eric Anholt <eric@anholt.net>
> >
> > 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@gmail.com>
> >
> > 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].
>
> 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.
Thanks
Stefan
>
> [1] - https://patchwork.kernel.org/patch/9612613/
^ permalink raw reply
* Re: [PATCH v7 00/13] mmc: Add support to Marvell Xenon SD Host Controller
From: Russell King - ARM Linux @ 2017-03-30 18:56 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Ulf Hansson, Adrian Hunter, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Jimmy Xu, Andrew Lunn, Mike Turquette, Nadav Haklai, Ziji Hu,
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
In-Reply-To: <cover.51071caa64e5df81264a91b9a81ed1e94f47d2c4.1490886907.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
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?
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] usb: add DT bindings for farady fotg2 host controller
From: Hans Ulli Kroll @ 2017-03-30 18:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Hans Ulli Kroll, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, Linux USB List, Greg Kroah-Hartman,
Mark Rutland
In-Reply-To: <CACRpkdbjNS+ADawDCub5OP1iguNk+4Ked+mh_T_-bJ=6-9-3Nw@mail.gmail.com>
Hi Linus,
On Thu, 30 Mar 2017, Linus Walleij wrote:
> On Tue, Feb 21, 2017 at 3:43 PM, Rob Herring <robh@kernel.org> wrote:
> > On Fri, Feb 17, 2017 at 4:07 AM, Hans Ulli Kroll
> > <ulli.kroll@googlemail.com> wrote:
> >> Hi Rob,
> >>
> >> On Wed, 15 Feb 2017, Rob Herring wrote:
> >>
> >>> On Wed, Feb 08, 2017 at 09:00:09PM +0100, Hans Ulli Kroll wrote:
> >>> > This adds DT bindings for the Faraday FOTG2 host controller.
> >>> >
> >>> > Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> >>> > ---
> >>> > Documentation/devicetree/bindings/usb/fotg2-host.txt | 15 +++++++++++++++
> >>> > 1 file changed, 15 insertions(+)
> >>> > create mode 100644 Documentation/devicetree/bindings/usb/fotg2-host.txt
> >>> >
> >>> > diff --git a/Documentation/devicetree/bindings/usb/fotg2-host.txt b/Documentation/devicetree/bindings/usb/fotg2-host.txt
> >>> > new file mode 100644
> >>> > index 000000000000..4c07566a4bf5
> >>> > --- /dev/null
> >>> > +++ b/Documentation/devicetree/bindings/usb/fotg2-host.txt
> >>> > @@ -0,0 +1,15 @@
> >>> > +Faraday FOTG Host controller
> >>> > +
> >>> > +Required properties:
> >>> > +
> >>> > +- compatible: should be "faraday,fotg210-hcd"
> >>>
> >>> hcd as in "host controller driver"? Bindings describe h/w not drivers.
> >>>
> >>> It's an OTG controller or host controller?
> >>>
> >>
> >> here only the host controller part used.
> >>
> >> faraday fotg2 is a dual role hcd/otg device and here is only the
> >> host part used.
> >
> > Because you don't care about device mode or restricted by the IP
> > configuration or SoC integration? The former is a user choice and
> > shouldn't be part of DT. The latter should be implied by an SoC
> > specific compatible string. Using only a compatible string for a
> > licensed IP is not specific enough as vendors use differing versions
> > and integrate them in different ways.
>
> Hans can you add:
>
> compatible = "cortina,gemini-fotg", "faraday,fotg210-hcd" or something
> as composite compatible for our controller?
>
I prefer
"faraday,fotg210-usb2"
I've got rejected by Rob due the fact this is an dual role controller,
which supports both host and device mode. And DT must reflect this desgn
pattern.
Currently I'm wrappingt my head around the design of the fsl-mph-dr-of.c
driver to use this as a blueprint for the Faraday driver.
Greetings
Hans Ulli Kroll
^ permalink raw reply
* Re: [PATCHv3] iio: adc: cpcap: Add minimal support for CPCAP PMIC ADC
From: Jonathan Cameron @ 2017-03-30 18:26 UTC (permalink / raw)
To: Rob Herring, Tony Lindgren
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Michael Scott,
Sebastian Reichel
In-Reply-To: <20170329212637.syluvxy5cp2qub3h@rob-hp-laptop>
On 29/03/17 22:26, Rob Herring wrote:
> On Thu, Mar 23, 2017 at 08:38:42PM -0700, Tony Lindgren wrote:
>> On Motorola phones like droid 4 there is a custom CPCAP PMIC. This PMIC
>> has ADCs that are used for battery charging and USB PHY VBUS and ID pin
>> detection.
>>
>> Unfortunately the only documentation for this ADC seems to be the
>> Motorola mapphone Linux kernel tree. I have tested that reading raw and
>> scaled values works, but I have not used the timed sampling that the ADC
>> seems to support.
>>
>> Let's add a minimal support for it so we can eventually provide IIO
>> channels for the related battery charging and USB PHY drivers.
>>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: Marcel Partap <mpartap-hi6Y0CQ0nG0@public.gmane.org>
>> Cc: Michael Scott <michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>> ---
>>
>> Changes since v2:
>>
>> - Simplify things further by using channel based indexing and
>> remove more drivers specific enumerations
>>
>> Changes since v1:
>>
>> - Fix numerous issues pointed out by Peter Meerwald-Stadler
>> <pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org> and Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> - Simplify things further by limiting read functions to a
>> single channel instead of a bank and got rid of the driver
>> specific cpcap_adc_conv_type in favor of IIO generic types
>>
>> ---
>> .../devicetree/bindings/iio/adc/cpcap-adc.txt | 18 +
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Been long enough now that I'm happy to take this.
Thanks for looking at the bindings Rob!
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Jonathan
>
>> drivers/iio/adc/Kconfig | 11 +
>> drivers/iio/adc/Makefile | 1 +
>> drivers/iio/adc/cpcap-adc.c | 1007 ++++++++++++++++++++
>> 4 files changed, 1037 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/adc/cpcap-adc.txt
>> create mode 100644 drivers/iio/adc/cpcap-adc.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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 0/6] bus: brcmstb_gisb: add support for GISBv7 arbiter
From: Mark Rutland @ 2017-03-30 18:19 UTC (permalink / raw)
To: Florian Fainelli
Cc: Doug Berger, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
olof-nZhT3qVonbNeoWH0uzbU5w, mirza.krak-Re5JQEeQqe8AvxtiuMwx3w,
suzuki.poulose-5wv7dgnIgG8, bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8
In-Reply-To: <c3182c24-2245-cf2e-32e4-248b8046a30f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Mar 30, 2017 at 09:33:32AM -0700, Florian Fainelli wrote:
> On 03/29/2017 05:29 PM, Doug Berger wrote:
> > This patch set contains changes to enable the GISB arbiter driver
> > on the latest ARM64 architecture Set-Top Box chips from Broadcom.
> >
> > Since the ARM64 architecture does not support the hooking of low
> > level fault handlers the driver has been adjusted to depend solely
> > on GISB interrupts and notify events to provide diagnostic
> > messaging. The GISB hardware still triggers bus faults for the
> > processor so the default low-level aborts will occur and will be
> > handled based on the architecture specific kernel implementation.
> >
> > While this tends to obsure the GISB error messaging it is still
> > reasonable so the same approach is applied to the ARM architecture
> > for consistency.
> >
> > The patches also correct some issues with the existing driver
> > and add the new register map for the GISBv7 hardware first
> > appearing in the BCM7278 device.
>
> This all looks great to me, and since there are no more ARM64
> dependencies I can take this via the Broadcom ARM/ARM64 SoC pull requests.
>
> Mark, are you also happy with this v3?
It looks fine by me.
Thanks,
Mark.
--
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 v4 19/23] drivers/fsi: Add GPIO based FSI master
From: Christopher Bostic @ 2017-03-30 18:15 UTC (permalink / raw)
To: Joel Stanley
Cc: Rob Herring, Mark Rutland, Russell King,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
Greg KH, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Linux Kernel Mailing List, Andrew Jeffery, Alistair Popple,
Benjamin Herrenschmidt, Edward A . James, Jeremy Kerr
In-Reply-To: <CACPK8XfOSYPidHF6=psC4mP-tkRyWTu0psdcK6EwA2E6FF53Uw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 3/30/17 12:48 AM, Joel Stanley wrote:
> On Thu, Mar 30, 2017 at 4:13 AM, Christopher Bostic
> <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
>> From: Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>
>> Implement a FSI master using GPIO. Will generate FSI protocol for
>> read and write commands to particular addresses. Sends master command
>> and waits for and decodes a slave response.
>>
>> Includes changes from Edward A. James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> and Jeremy
>> Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>.
>>
>> Signed-off-by: Edward A. James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>> ---
>> arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 10 +
>> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 12 +
>> drivers/fsi/Kconfig | 11 +
>> drivers/fsi/Makefile | 1 +
>> drivers/fsi/fsi-master-gpio.c | 614 ++++++++++++++++++++++++++
>> 5 files changed, 648 insertions(+)
>> create mode 100644 drivers/fsi/fsi-master-gpio.c
>>
>> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
>> index 1d2fc1e..cf7d7d7 100644
>> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
>> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
>> @@ -29,6 +29,16 @@
>> reg = <0x5f000000 0x01000000>; /* 16M */
>> };
>> };
>> +
>> + gpio-fsi {
>> + compatible = "fsi-master-gpio", "fsi-master";
>> +
>> + clock-gpios = <&gpio ASPEED_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
>> + data-gpios = <&gpio ASPEED_GPIO(A, 5) GPIO_ACTIVE_HIGH>;
>> + mux-gpios = <&gpio ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
>> + enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
>> + trans-gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_HIGH>;
>> + };
>> };
>>
>> &uart5 {
>> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
>> index 7a3b2b5..2fd7db7 100644
>> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
>> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
>> @@ -29,6 +29,18 @@
>> reg = <0xbf000000 0x01000000>; /* 16M */
>> };
>> };
>> +
>> + gpio-fsi {
>> + compatible = "fsi-master-gpio", "fsi-master";
>> +
>> + status = "okay";
>> +
>> + clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
>> + data-gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
>> + mux-gpios = <&gpio ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
>> + enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
>> + trans-gpios = <&gpio ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
>> + };
>> };
> I'm not sure what happened here. The changes to the device trees
> should not be in this patch.
Where would you recommend they be placed? I assume we want them
somewhere in the patch set.
Thanks,
Chris
> Cheers,
>
> Joel
>
>> &uart5 {
>> diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
>> index 04c1a0e..9cf8345 100644
>> --- a/drivers/fsi/Kconfig
>> +++ b/drivers/fsi/Kconfig
>> @@ -9,4 +9,15 @@ config FSI
>> ---help---
>> FSI - the FRU Support Interface - is a simple bus for low-level
>> access to POWER-based hardware.
>> +
>> +if FSI
>> +
>> +config FSI_MASTER_GPIO
>> + tristate "GPIO-based FSI master"
>> + depends on FSI && GPIOLIB
>> + ---help---
>> + This option enables a FSI master driver using GPIO lines.
>> +
>> +endif
>> +
>> endmenu
>> diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
>> index db0e5e7..ed28ac0 100644
>> --- a/drivers/fsi/Makefile
>> +++ b/drivers/fsi/Makefile
>> @@ -1,2 +1,3 @@
>>
>> obj-$(CONFIG_FSI) += fsi-core.o
>> +obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
>> diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c
>> new file mode 100644
>> index 0000000..0bf5caa
>> --- /dev/null
>> +++ b/drivers/fsi/fsi-master-gpio.c
>> @@ -0,0 +1,614 @@
>> +/*
>> + * A FSI master controller, using a simple GPIO bit-banging interface
>> + */
>> +
>> +#include <linux/platform_device.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fsi.h>
>> +#include <linux/device.h>
>> +#include <linux/io.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +
>> +#include "fsi-master.h"
>> +
>> +#define FSI_GPIO_STD_DLY 1 /* Standard pin delay in nS */
>> +#define FSI_ECHO_DELAY_CLOCKS 16 /* Number clocks for echo delay */
>> +#define FSI_PRE_BREAK_CLOCKS 50 /* Number clocks to prep for break */
>> +#define FSI_BREAK_CLOCKS 256 /* Number of clocks to issue break */
>> +#define FSI_POST_BREAK_CLOCKS 16000 /* Number clocks to set up cfam */
>> +#define FSI_INIT_CLOCKS 5000 /* Clock out any old data */
>> +#define FSI_GPIO_STD_DELAY 10 /* Standard GPIO delay in nS */
>> + /* todo: adjust down as low as */
>> + /* possible or eliminate */
>> +#define FSI_GPIO_CMD_DPOLL 0x2
>> +#define FSI_GPIO_CMD_TERM 0x3f
>> +#define FSI_GPIO_CMD_ABS_AR 0x4
>> +
>> +#define FSI_GPIO_DPOLL_CLOCKS 100 /* < 21 will cause slave to hang */
>> +
>> +/* Bus errors */
>> +#define FSI_GPIO_ERR_BUSY 1 /* Slave stuck in busy state */
>> +#define FSI_GPIO_RESP_ERRA 2 /* Any (misc) Error */
>> +#define FSI_GPIO_RESP_ERRC 3 /* Slave reports master CRC error */
>> +#define FSI_GPIO_MTOE 4 /* Master time out error */
>> +#define FSI_GPIO_CRC_INVAL 5 /* Master reports slave CRC error */
>> +
>> +/* Normal slave responses */
>> +#define FSI_GPIO_RESP_BUSY 1
>> +#define FSI_GPIO_RESP_ACK 0
>> +#define FSI_GPIO_RESP_ACKD 4
>> +
>> +#define FSI_GPIO_MAX_BUSY 100
>> +#define FSI_GPIO_MTOE_COUNT 1000
>> +#define FSI_GPIO_DRAIN_BITS 20
>> +#define FSI_GPIO_CRC_SIZE 4
>> +#define FSI_GPIO_MSG_ID_SIZE 2
>> +#define FSI_GPIO_MSG_RESPID_SIZE 2
>> +#define FSI_GPIO_PRIME_SLAVE_CLOCKS 100
>> +
>> +static DEFINE_SPINLOCK(fsi_gpio_cmd_lock); /* lock around fsi commands */
>> +
>> +struct fsi_master_gpio {
>> + struct fsi_master master;
>> + struct device *dev;
>> + struct gpio_desc *gpio_clk;
>> + struct gpio_desc *gpio_data;
>> + struct gpio_desc *gpio_trans; /* Voltage translator */
>> + struct gpio_desc *gpio_enable; /* FSI enable */
>> + struct gpio_desc *gpio_mux; /* Mux control */
>> +};
>> +
>> +#define to_fsi_master_gpio(m) container_of(m, struct fsi_master_gpio, master)
>> +
>> +struct fsi_gpio_msg {
>> + uint64_t msg;
>> + uint8_t bits;
>> +};
>> +
>> +static void clock_toggle(struct fsi_master_gpio *master, int count)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < count; i++) {
>> + ndelay(FSI_GPIO_STD_DLY);
>> + gpiod_set_value(master->gpio_clk, 0);
>> + ndelay(FSI_GPIO_STD_DLY);
>> + gpiod_set_value(master->gpio_clk, 1);
>> + }
>> +}
>> +
>> +static int sda_in(struct fsi_master_gpio *master)
>> +{
>> + int in;
>> +
>> + ndelay(FSI_GPIO_STD_DLY);
>> + in = gpiod_get_value(master->gpio_data);
>> + return in ? 1 : 0;
>> +}
>> +
>> +static void sda_out(struct fsi_master_gpio *master, int value)
>> +{
>> + gpiod_set_value(master->gpio_data, value);
>> +}
>> +
>> +static void set_sda_input(struct fsi_master_gpio *master)
>> +{
>> + gpiod_direction_input(master->gpio_data);
>> + if (master->gpio_trans)
>> + gpiod_set_value(master->gpio_trans, 0);
>> +}
>> +
>> +static void set_sda_output(struct fsi_master_gpio *master, int value)
>> +{
>> + if (master->gpio_trans)
>> + gpiod_set_value(master->gpio_trans, 1);
>> + gpiod_direction_output(master->gpio_data, value);
>> +}
>> +
>> +static void clock_zeros(struct fsi_master_gpio *master, int count)
>> +{
>> + set_sda_output(master, 1);
>> + clock_toggle(master, count);
>> +}
>> +
>> +static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg *msg,
>> + uint8_t num_bits)
>> +{
>> + uint8_t bit, in_bit;
>> +
>> + set_sda_input(master);
>> +
>> + for (bit = 0; bit < num_bits; bit++) {
>> + clock_toggle(master, 1);
>> + in_bit = sda_in(master);
>> + msg->msg <<= 1;
>> + msg->msg |= ~in_bit & 0x1; /* Data is negative active */
>> + }
>> + msg->bits += num_bits;
>> +}
>> +
>> +static void serial_out(struct fsi_master_gpio *master,
>> + const struct fsi_gpio_msg *cmd)
>> +{
>> + uint8_t bit;
>> + uint64_t msg = ~cmd->msg; /* Data is negative active */
>> + uint64_t sda_mask = 0x1ULL << (cmd->bits - 1);
>> + uint64_t last_bit = ~0;
>> + int next_bit;
>> +
>> + if (!cmd->bits) {
>> + dev_warn(master->dev, "trying to output 0 bits\n");
>> + return;
>> + }
>> + set_sda_output(master, 0);
>> +
>> + /* Send the start bit */
>> + sda_out(master, 0);
>> + clock_toggle(master, 1);
>> +
>> + /* Send the message */
>> + for (bit = 0; bit < cmd->bits; bit++) {
>> + next_bit = (msg & sda_mask) >> (cmd->bits - 1);
>> + if (last_bit ^ next_bit) {
>> + sda_out(master, next_bit);
>> + last_bit = next_bit;
>> + }
>> + clock_toggle(master, 1);
>> + msg <<= 1;
>> + }
>> +}
>> +
>> +static void msg_push_bits(struct fsi_gpio_msg *msg, uint64_t data, int bits)
>> +{
>> + msg->msg <<= bits;
>> + msg->msg |= data & ((1ull << bits) - 1);
>> + msg->bits += bits;
>> +}
>> +
>> +static void msg_push_crc(struct fsi_gpio_msg *msg)
>> +{
>> + uint8_t crc;
>> + int top;
>> +
>> + top = msg->bits & 0x3;
>> +
>> + /* start bit, and any non-aligned top bits */
>> + crc = fsi_crc4(0,
>> + 1 << top | msg->msg >> (msg->bits - top),
>> + top + 1);
>> +
>> + /* aligned bits */
>> + crc = fsi_crc4(crc, msg->msg, msg->bits - top);
>> +
>> + msg_push_bits(msg, crc, 4);
>> +}
>> +
>> +static void build_abs_ar_command(struct fsi_gpio_msg *cmd,
>> + uint8_t id, uint32_t addr, size_t size, const void *data)
>> +{
>> + bool write = !!data;
>> + uint8_t ds;
>> + int i;
>> +
>> + cmd->bits = 0;
>> + cmd->msg = 0;
>> +
>> + msg_push_bits(cmd, id, 2);
>> + msg_push_bits(cmd, FSI_GPIO_CMD_ABS_AR, 3);
>> + msg_push_bits(cmd, write ? 0 : 1, 1);
>> +
>> + /*
>> + * The read/write size is encoded in the lower bits of the address
>> + * (as it must be naturally-aligned), and the following ds bit.
>> + *
>> + * size addr:1 addr:0 ds
>> + * 1 x x 0
>> + * 2 x 0 1
>> + * 4 0 1 1
>> + *
>> + */
>> + ds = size > 1 ? 1 : 0;
>> + addr &= ~(size - 1);
>> + if (size == 4)
>> + addr |= 1;
>> +
>> + msg_push_bits(cmd, addr & ((1 << 21) - 1), 21);
>> + msg_push_bits(cmd, ds, 1);
>> + for (i = 0; write && i < size; i++)
>> + msg_push_bits(cmd, ((uint8_t *)data)[i], 8);
>> +
>> + msg_push_crc(cmd);
>> +}
>> +
>> +static void build_dpoll_command(struct fsi_gpio_msg *cmd, uint8_t slave_id)
>> +{
>> + cmd->bits = 0;
>> + cmd->msg = 0;
>> +
>> + msg_push_bits(cmd, slave_id, 2);
>> + msg_push_bits(cmd, FSI_GPIO_CMD_DPOLL, 3);
>> + msg_push_crc(cmd);
>> +}
>> +
>> +static void echo_delay(struct fsi_master_gpio *master)
>> +{
>> + set_sda_output(master, 1);
>> + clock_toggle(master, FSI_ECHO_DELAY_CLOCKS);
>> +}
>> +
>> +static void build_term_command(struct fsi_gpio_msg *cmd, uint8_t slave_id)
>> +{
>> + cmd->bits = 0;
>> + cmd->msg = 0;
>> +
>> + msg_push_bits(cmd, slave_id, 2);
>> + msg_push_bits(cmd, FSI_GPIO_CMD_TERM, 6);
>> + msg_push_crc(cmd);
>> +}
>> +
>> +/*
>> + * Store information on master errors so handler can detect and clean
>> + * up the bus
>> + */
>> +static void fsi_master_gpio_error(struct fsi_master_gpio *master, int error)
>> +{
>> +
>> +}
>> +
>> +static int read_one_response(struct fsi_master_gpio *master,
>> + uint8_t data_size, struct fsi_gpio_msg *msgp, uint8_t *tagp)
>> +{
>> + struct fsi_gpio_msg msg;
>> + uint8_t id, tag;
>> + uint32_t crc;
>> + int i;
>> +
>> + /* wait for the start bit */
>> + for (i = 0; i < FSI_GPIO_MTOE_COUNT; i++) {
>> + msg.bits = 0;
>> + msg.msg = 0;
>> + serial_in(master, &msg, 1);
>> + if (msg.msg)
>> + break;
>> + }
>> + if (i >= FSI_GPIO_MTOE_COUNT) {
>> + dev_dbg(master->dev,
>> + "Master time out waiting for response\n");
>> + fsi_master_gpio_error(master, FSI_GPIO_MTOE);
>> + return -EIO;
>> + }
>> +
>> + msg.bits = 0;
>> + msg.msg = 0;
>> +
>> + /* Read slave ID & response tag */
>> + serial_in(master, &msg, 4);
>> +
>> + id = (msg.msg >> FSI_GPIO_MSG_RESPID_SIZE) & 0x3;
>> + tag = msg.msg & 0x3;
>> +
>> + /* if we have an ACK, and we're expecting data, clock the
>> + * data in too
>> + */
>> + if (tag == FSI_GPIO_RESP_ACK && data_size)
>> + serial_in(master, &msg, data_size * 8);
>> +
>> + /* read CRC */
>> + serial_in(master, &msg, FSI_GPIO_CRC_SIZE);
>> +
>> + /* we have a whole message now; check CRC */
>> + crc = fsi_crc4(0, 1, 1);
>> + crc = fsi_crc4(crc, msg.msg, msg.bits);
>> + if (crc) {
>> + dev_dbg(master->dev, "ERR response CRC\n");
>> + fsi_master_gpio_error(master, FSI_GPIO_CRC_INVAL);
>> + return -EIO;
>> + }
>> +
>> + if (msgp)
>> + *msgp = msg;
>> + if (tagp)
>> + *tagp = tag;
>> +
>> + return 0;
>> +}
>> +
>> +static int issue_term(struct fsi_master_gpio *master, uint8_t slave)
>> +{
>> + struct fsi_gpio_msg cmd;
>> + uint8_t tag;
>> + int rc;
>> +
>> + build_term_command(&cmd, slave);
>> + serial_out(master, &cmd);
>> + echo_delay(master);
>> +
>> + rc = read_one_response(master, 0, NULL, &tag);
>> + if (rc) {
>> + dev_err(master->dev,
>> + "TERM failed; lost communication with slave\n");
>> + return -EIO;
>> + } else if (tag != FSI_GPIO_RESP_ACK) {
>> + dev_err(master->dev, "TERM failed; response %d\n", tag);
>> + return -EIO;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int poll_for_response(struct fsi_master_gpio *master,
>> + uint8_t slave, uint8_t size, void *data)
>> +{
>> + struct fsi_gpio_msg response, cmd;
>> + int busy_count = 0, rc, i;
>> + uint8_t tag;
>> +
>> +retry:
>> + rc = read_one_response(master, size, &response, &tag);
>> + if (rc)
>> + return rc;
>> +
>> + switch (tag) {
>> + case FSI_GPIO_RESP_ACK:
>> + if (size && data) {
>> + uint64_t val = response.msg;
>> + /* clear crc & mask */
>> + val >>= 4;
>> + val &= (1ull << (size * 8)) - 1;
>> +
>> + for (i = 0; i < size; i++) {
>> + ((uint8_t *)data)[size-i-1] =
>> + val & 0xff;
>> + val >>= 8;
>> + }
>> + }
>> + break;
>> + case FSI_GPIO_RESP_BUSY:
>> + /*
>> + * Its necessary to clock slave before issuing
>> + * d-poll, not indicated in the hardware protocol
>> + * spec. < 20 clocks causes slave to hang, 21 ok.
>> + */
>> + clock_zeros(master, FSI_GPIO_DPOLL_CLOCKS);
>> + if (busy_count++ < FSI_GPIO_MAX_BUSY) {
>> + build_dpoll_command(&cmd, slave);
>> + serial_out(master, &cmd);
>> + echo_delay(master);
>> + goto retry;
>> + }
>> + dev_warn(master->dev,
>> + "ERR slave is stuck in busy state, issuing TERM\n");
>> + issue_term(master, slave);
>> + rc = -EIO;
>> + break;
>> +
>> + case FSI_GPIO_RESP_ERRA:
>> + case FSI_GPIO_RESP_ERRC:
>> + dev_dbg(master->dev, "ERR%c received: 0x%x\n",
>> + tag == FSI_GPIO_RESP_ERRA ? 'A' : 'C',
>> + (int)response.msg);
>> + fsi_master_gpio_error(master, response.msg);
>> + rc = -EIO;
>> + break;
>> + }
>> +
>> + /* Clock the slave enough to be ready for next operation */
>> + clock_zeros(master, FSI_GPIO_PRIME_SLAVE_CLOCKS);
>> + return rc;
>> +}
>> +
>> +static int fsi_master_gpio_xfer(struct fsi_master_gpio *master, uint8_t slave,
>> + struct fsi_gpio_msg *cmd, size_t resp_len, void *resp)
>> +{
>> + unsigned long flags;
>> + int rc;
>> +
>> + spin_lock_irqsave(&fsi_gpio_cmd_lock, flags);
>> + serial_out(master, cmd);
>> + echo_delay(master);
>> + rc = poll_for_response(master, slave, resp_len, resp);
>> + spin_unlock_irqrestore(&fsi_gpio_cmd_lock, flags);
>> +
>> + return rc;
>> +}
>> +
>> +static int fsi_master_gpio_read(struct fsi_master *_master, int link,
>> + uint8_t id, uint32_t addr, void *val, size_t size)
>> +{
>> + struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
>> + struct fsi_gpio_msg cmd;
>> +
>> + if (link != 0)
>> + return -ENODEV;
>> +
>> + build_abs_ar_command(&cmd, id, addr, size, NULL);
>> + return fsi_master_gpio_xfer(master, id, &cmd, size, val);
>> +}
>> +
>> +static int fsi_master_gpio_write(struct fsi_master *_master, int link,
>> + uint8_t id, uint32_t addr, const void *val, size_t size)
>> +{
>> + struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
>> + struct fsi_gpio_msg cmd;
>> +
>> + if (link != 0)
>> + return -ENODEV;
>> +
>> + build_abs_ar_command(&cmd, id, addr, size, val);
>> + return fsi_master_gpio_xfer(master, id, &cmd, 0, NULL);
>> +}
>> +
>> +static int fsi_master_gpio_term(struct fsi_master *_master,
>> + int link, uint8_t id)
>> +{
>> + struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
>> + struct fsi_gpio_msg cmd;
>> +
>> + if (link != 0)
>> + return -ENODEV;
>> +
>> + build_term_command(&cmd, id);
>> + return fsi_master_gpio_xfer(master, id, &cmd, 0, NULL);
>> +}
>> +
>> +/*
>> + * Issue a break command on link
>> + */
>> +static int fsi_master_gpio_break(struct fsi_master *_master, int link)
>> +{
>> + struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
>> +
>> + if (link != 0)
>> + return -ENODEV;
>> +
>> + set_sda_output(master, 1);
>> + sda_out(master, 1);
>> + clock_toggle(master, FSI_PRE_BREAK_CLOCKS);
>> + sda_out(master, 0);
>> + clock_toggle(master, FSI_BREAK_CLOCKS);
>> + echo_delay(master);
>> + sda_out(master, 1);
>> + clock_toggle(master, FSI_POST_BREAK_CLOCKS);
>> +
>> + /* Wait for logic reset to take effect */
>> + udelay(200);
>> +
>> + return 0;
>> +}
>> +
>> +static void fsi_master_gpio_init(struct fsi_master_gpio *master)
>> +{
>> + if (master->gpio_mux)
>> + gpiod_direction_output(master->gpio_mux, 1);
>> + if (master->gpio_trans)
>> + gpiod_direction_output(master->gpio_trans, 1);
>> + if (master->gpio_enable)
>> + gpiod_direction_output(master->gpio_enable, 1);
>> + gpiod_direction_output(master->gpio_clk, 1);
>> + gpiod_direction_output(master->gpio_data, 1);
>> +
>> + /* todo: evaluate if clocks can be reduced */
>> + clock_zeros(master, FSI_INIT_CLOCKS);
>> +}
>> +
>> +static int fsi_master_gpio_link_enable(struct fsi_master *_master, int link)
>> +{
>> + struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
>> +
>> + if (link != 0)
>> + return -ENODEV;
>> + if (master->gpio_enable)
>> + gpiod_set_value(master->gpio_enable, 1);
>> +
>> + return 0;
>> +}
>> +
>> +static void fsi_master_gpio_release(struct device *dev)
>> +{
>> + struct fsi_master_gpio *master = to_fsi_master_gpio(
>> + dev_to_fsi_master(dev));
>> +
>> + kfree(master);
>> +}
>> +
>> +static int fsi_master_gpio_probe(struct platform_device *pdev)
>> +{
>> + struct fsi_master_gpio *master;
>> + struct gpio_desc *gpio;
>> +
>> + master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
>> + if (!master)
>> + return -ENOMEM;
>> +
>> + master->dev = &pdev->dev;
>> + master->master.dev.parent = master->dev;
>> + master->master.dev.release = fsi_master_gpio_release;
>> +
>> + gpio = devm_gpiod_get(&pdev->dev, "clock", 0);
>> + if (IS_ERR(gpio)) {
>> + dev_err(&pdev->dev, "failed to get clock gpio\n");
>> + return PTR_ERR(gpio);
>> + }
>> + master->gpio_clk = gpio;
>> +
>> + gpio = devm_gpiod_get(&pdev->dev, "data", 0);
>> + if (IS_ERR(gpio)) {
>> + dev_err(&pdev->dev, "failed to get data gpio\n");
>> + return PTR_ERR(gpio);
>> + }
>> + master->gpio_data = gpio;
>> +
>> + /* Optional GPIOs */
>> + gpio = devm_gpiod_get_optional(&pdev->dev, "trans", 0);
>> + if (IS_ERR(gpio)) {
>> + dev_err(&pdev->dev, "failed to get trans gpio\n");
>> + return PTR_ERR(gpio);
>> + }
>> + master->gpio_trans = gpio;
>> +
>> + gpio = devm_gpiod_get_optional(&pdev->dev, "enable", 0);
>> + if (IS_ERR(gpio)) {
>> + dev_err(&pdev->dev, "failed to get enable gpio\n");
>> + return PTR_ERR(gpio);
>> + }
>> + master->gpio_enable = gpio;
>> +
>> + gpio = devm_gpiod_get_optional(&pdev->dev, "mux", 0);
>> + if (IS_ERR(gpio)) {
>> + dev_err(&pdev->dev, "failed to get mux gpio\n");
>> + return PTR_ERR(gpio);
>> + }
>> + master->gpio_mux = gpio;
>> +
>> + master->master.n_links = 1;
>> + master->master.read = fsi_master_gpio_read;
>> + master->master.write = fsi_master_gpio_write;
>> + master->master.term = fsi_master_gpio_term;
>> + master->master.send_break = fsi_master_gpio_break;
>> + master->master.link_enable = fsi_master_gpio_link_enable;
>> + platform_set_drvdata(pdev, master);
>> +
>> + fsi_master_gpio_init(master);
>> +
>> + fsi_master_register(&master->master);
>> +
>> + return 0;
>> +}
>> +
>> +
>> +static int fsi_master_gpio_remove(struct platform_device *pdev)
>> +{
>> + struct fsi_master_gpio *master = platform_get_drvdata(pdev);
>> +
>> + devm_gpiod_put(&pdev->dev, master->gpio_clk);
>> + devm_gpiod_put(&pdev->dev, master->gpio_data);
>> + if (master->gpio_trans)
>> + devm_gpiod_put(&pdev->dev, master->gpio_trans);
>> + if (master->gpio_enable)
>> + devm_gpiod_put(&pdev->dev, master->gpio_enable);
>> + if (master->gpio_mux)
>> + devm_gpiod_put(&pdev->dev, master->gpio_mux);
>> + fsi_master_unregister(&master->master);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id fsi_master_gpio_match[] = {
>> + { .compatible = "fsi-master-gpio" },
>> + { },
>> +};
>> +
>> +static struct platform_driver fsi_master_gpio_driver = {
>> + .driver = {
>> + .name = "fsi-master-gpio",
>> + .of_match_table = fsi_master_gpio_match,
>> + },
>> + .probe = fsi_master_gpio_probe,
>> + .remove = fsi_master_gpio_remove,
>> +};
>> +
>> +module_platform_driver(fsi_master_gpio_driver);
>> +MODULE_LICENSE("GPL");
>> --
>> 1.8.2.2
>>
--
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: Cyrille Pitchen @ 2017-03-30 17:40 UTC (permalink / raw)
To: Guochun Mao, Boris Brezillon, Marek Vasut
Cc: Mark Rutland, devicetree, Richard Weinberger, Russell King,
linux-kernel, Rob Herring, linux-mtd, Matthias Brugger,
linux-mediatek, Cyrille Pitchen, David Woodhouse,
linux-arm-kernel
In-Reply-To: <1490862222-723-2-git-send-email-guochun.mao@mediatek.com>
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@mediatek.com>
> ---
> 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.
SPI controller driver should never check SPINOR_OP_* op codes like this.
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)
>
^ permalink raw reply
* [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1
From: Philipp Zabel @ 2017-03-30 17:25 UTC (permalink / raw)
To: Steve Longerbeam
Cc: robh+dt, mark.rutland, shawnguo, kernel, fabio.estevam, linux,
mchehab, hverkuil, nick, markus.heiser, laurent.pinchart+renesas,
bparrot, geert, arnd, sudipm.mukherjee, minghsiu.tsai,
tiffany.lin, jean-christophe.trotin, horms+renesas,
niklas.soderlund+renesas, robert.jarzmik, songjun.wu,
andrew-ct.chen, gregkh, shuah, sakari.ailus, pavel, devicetree,
linux-kernel, linux-arm-kernel, linux-media
In-Reply-To: <1490661656-10318-20-git-send-email-steve_longerbeam@mentor.com>
The TVP5150 DT bindings specify a single output port (port 0) that
corresponds to the video output pad (pad 1, DEMOD_PAD_VID_OUT).
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
I'm trying to get this to work with a TVP5150 analog TV decoder, and the
first problem is that this device doesn't have pad 0 as its single
output pad. Instead, as a MEDIA_ENT_F_ATV_DECODER entity, it has for
pads (input, video out, vbi out, audio out), and video out is pad 1,
whereas the device tree only defines a single port (0).
---
drivers/staging/media/imx/imx-media-dev.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
index 17e2386a3ca3a..c52d6ca797965 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -267,6 +267,15 @@ static int imx_media_create_link(struct imx_media_dev *imxmd,
source_pad = link->local_pad;
sink_pad = link->remote_pad;
+ /*
+ * If the source subdev is an analog video decoder with a single source
+ * port, assume that this port 0 corresponds to the DEMOD_PAD_VID_OUT
+ * entity pad.
+ */
+ if (source->entity.function == MEDIA_ENT_F_ATV_DECODER &&
+ local_sd->num_sink_pads == 0 && local_sd->num_src_pads == 1)
+ source_pad = DEMOD_PAD_VID_OUT;
+
v4l2_info(&imxmd->v4l2_dev, "%s: %s:%d -> %s:%d\n", __func__,
source->name, source_pad, sink->name, sink_pad);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Gregory CLEMENT @ 2017-03-30 16:57 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-gpio@vger.kernel.org, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Rob Herring,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <CACRpkdYA9xq3TmW-=0+cxdeBcq6v3HAFf3f5E-FAvUpGZqns3g@mail.gmail.com>
Hi Linus,
On mer., mars 29 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> It has irq_create_mapping(gpiochip->irqdomain, offset); that get
>>> called for every IRQ, and that will eventually call irq_of_parse_and_map()
>>> if the IRQs are defined in the device tree. (IIRC)
>>
>> When I followed the functions called I never find a call to
>> irq_of_parse_and_map(), the closer things related to device tree I found
>> was:
>> "virq = irq_domain_alloc_descs(-1, 1, hwirq, of_node_to_nid(of_node),
>> NULL);"
>> http://elixir.free-electrons.com/source/kernel/irq/irqdomain.c?v=4.11-rc4#L507
>
> I don't know if I'm rambling or what. I'm pretty sure it gets called, maybe
> even earlier, like when the DT is parsed for the platform. We have so many
> drivers not seemingly needing this, but if your driver needs it, all others
> may need to be fixed too.
>
> Can you put a print in irq_of_parse_and_map() and see what happens?
So if I don't call it explicitly in my driver, then this function is
never called for the gpio.
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: dts: armada-385-linksys: disk-activity trigger for all
From: Ralph Sennhauser @ 2017-03-30 16:54 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Ralph Sennhauser, Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Commit a4ee7e18d808 ("ARM: dts: armada: Add default trigger for sata
led") adds the default trigger to individual boards, move it to
armada-385-linksys.dtsi which effectively enables the definition for
the WRT1900ACS (Shelby) as well as for future boards.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/armada-385-linksys-caiman.dts | 1 -
arch/arm/boot/dts/armada-385-linksys-cobra.dts | 1 -
arch/arm/boot/dts/armada-385-linksys.dtsi | 1 +
3 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys-caiman.dts b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
index a1b6e68..f3cee91 100644
--- a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
+++ b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
@@ -109,7 +109,6 @@
sata {
label = "caiman:white:sata";
- linux,default-trigger = "disk-activity";
};
};
};
diff --git a/arch/arm/boot/dts/armada-385-linksys-cobra.dts b/arch/arm/boot/dts/armada-385-linksys-cobra.dts
index a1a75af..1110718 100644
--- a/arch/arm/boot/dts/armada-385-linksys-cobra.dts
+++ b/arch/arm/boot/dts/armada-385-linksys-cobra.dts
@@ -109,7 +109,6 @@
sata {
label = "cobra:white:sata";
- linux,default-trigger = "disk-activity";
};
};
};
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi b/arch/arm/boot/dts/armada-385-linksys.dtsi
index aa0d225..2306c45 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -320,6 +320,7 @@
sata {
gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
default-state = "off";
+ linux,default-trigger = "disk-activity";
};
};
--
2.10.2
--
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 v3 00/37] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
From: Boris Brezillon @ 2017-03-30 16:38 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Enrico Jorns,
Artem Bityutskiy, Dinh Nguyen, Marek Vasut, Graham Moore,
David Woodhouse, Masami Hiramatsu, Chuanxiao Dong, Jassi Brar,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On Thu, 30 Mar 2017 15:45:46 +0900
Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> wrote:
> This driver includes many problems.
>
> One of the biggest one is a bunch of hard-coded parameters. This IP
> has many parameters that can be customized when a delivery RTL is
> generated. However, this driver was upstreamed by Intel, with
> Intel parameters hard-coded. Later, Altera added denali_dt.c to use
> this driver for embedded boards, but they did not fix the code in
> denali.c So, this driver has never worked. Even some DT bindings
> actually turned out wrong.
>
> There are more problems: [1] The driver just retrieves the OOB area as-is
> whereas the controller uses syndrome page layout. [2] Many NAND chip
> specific parameters are hard-coded in the driver. [3] ONFi devices are
> not working [4] It can not read Bad Block Marker
>
> This patch series intends to solve those problems.
>
> Outstanding changes are:
> - Fix raw/oob callbacks for syndrome page layout
> - Implement setup_data_interface() callback
> - Fix/implement more commands for ONFi devices
> - Allow to skip the driver internal bounce buffer
> - Support PIO in case DMA is not supported
> - Switch from ->cmdfunc over to ->cmd_ctrl
>
> 18 patches were merged at v2.
> Here is the rest of the series.
>
> v1: https://lkml.org/lkml/2016/11/26/144
> v2: https://lkml.org/lkml/2017/3/22/804
>
>
> Masahiro Yamada (37):
> mtd: nand: relax ecc.read_page() return value for uncorrectable ECC
> mtd: nand: denali: allow to override mtd->name from label DT property
> mtd: nand: denali: remove meaningless pipeline read-ahead operation
> mtd: nand: denali: fix bitflips calculation in handle_ecc()
> mtd: nand: denali: fix erased page checking
> mtd: nand: denali: support HW_ECC_FIXUP capability
> mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant
> mtd: nand: denali: support 64bit capable DMA engine
> mtd: nand: denali_dt: remove dma-mask DT property
> mtd: nand: denali_dt: use pdev instead of ofdev for platform_device
> mtd: nand: denali: allow to override revision number
Applied patches 1 to 11.
> mtd: nand: denali: support 1024 byte ECC step size
> mtd: nand: denali: avoid hard-coding ecc.strength and ecc.bytes
> mtd: nand: denali: support "nand-ecc-strength" DT property
> mtd: nand: denali: remove Toshiba and Hynix specific fixup code
> mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
> mtd: nand: denali: set NAND_ECC_CUSTOM_PAGE_ACCESS
> mtd: nand: denali: do not propagate NAND_STATUS_FAIL to waitfunc()
> mtd: nand: denali: use BIT() and GENMASK() for register macros
> mtd: nand: denali: remove unneeded find_valid_banks()
> mtd: nand: denali: handle timing parameters by setup_data_interface()
> mtd: nand: denali: rework interrupt handling
> mtd: nand: denali: fix NAND_CMD_STATUS handling
> mtd: nand: denali: fix NAND_CMD_PARAM handling
> mtd: nand: denali: switch over to cmd_ctrl instead of cmdfunc
> mtd: nand: denali: fix bank reset function
> mtd: nand: denali: use interrupt instead of polling for bank reset
> mtd: nand: denali: propagate page to helpers via function argument
> mtd: nand: denali: merge struct nand_buf into struct denali_nand_info
> mtd: nand: denali: use flag instead of register macro for direction
> mtd: nand: denali: fix raw and oob accessors for syndrome page layout
> mtd: nand: denali: support hardware-assisted erased page detection
> mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset
> mtd: nand: allow drivers to request minimum alignment for passed
> buffer
> mtd: nand: denali: skip driver internal bounce buffer when possible
> mtd: nand: denali: use non-managed kmalloc() for DMA buffer
> mtd: nand: denali: enable bad block table scan
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.
>
> .../devicetree/bindings/mtd/denali-nand.txt | 24 +-
> drivers/mtd/nand/denali.c | 1971 ++++++++++----------
> drivers/mtd/nand/denali.h | 308 +--
> drivers/mtd/nand/denali_dt.c | 90 +-
> drivers/mtd/nand/denali_pci.c | 10 +-
> drivers/mtd/nand/nand_base.c | 49 +-
> include/linux/mtd/nand.h | 4 +-
> 7 files changed, 1234 insertions(+), 1222 deletions(-)
>
--
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