* Re: [RFC PATCH] of: Fix DMA configuration for non-DT masters
From: Oza Oza via iommu @ 2017-03-30 10:12 UTC (permalink / raw)
To: Robin Murphy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Linux IOMMU,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAMSpPPfw3+vDoD_rJD9Ny=kUtXf2v6Fm6Qksi=K=OEhfVNYy1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Mar 30, 2017 at 8:51 AM, Oza Oza <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On Wed, Mar 29, 2017 at 11:12 PM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
>> On 29/03/17 06:46, Oza Oza wrote:
>>> On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>>> On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
>>>>> For PCI masters not represented in DT, we pass the OF node of their
>>>>> associated host bridge to of_dma_configure(), such that they can inherit
>>>>> the appropriate DMA configuration from whatever is described there.
>>>>> Unfortunately, whilst this has worked for the "dma-coherent" property,
>>>>> it turns out to miss the case where the host bridge node has a non-empty
>>>>> "dma-ranges", since nobody is expecting the 'device' to be a bus itself.
>>>>>
>>>>> It transpires, though, that the de-facto interface since the prototype
>>>>> change in 1f5c69aa51f9 ("of: Move of_dma_configure() to device.c to help
>>>>> re-use") is very clear-cut: either the master_np argument is redundant
>>>>> with dev->of_node, or dev->of_node is NULL and master_np is the relevant
>>>>> parent bus. Let's ratify that behaviour, then teach the whole
>>>>> of_dma_configure() pipeline to cope with both cases properly.
>>>>>
>>>>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>>
>> [...]
>>
>>>>
>>>> pci and memory mapped device world is different.
>>
>> ???
>>
>> No they aren't. There is nothing magic about PCI. PCI *is* a
>> memory-mapped bus.
>>
>> The only PCI-specific aspect here is the Linux code path which passes a
>> host controller node into of_dma_configure() where the latter expects a
>> node for the actual endpoint device. It managed to work for
>> "dma-coherent", because that may appear either directly on a device node
>> or on any of its parent buses, but "dma-ranges" is *only* valid for DT
>> nodes representing buses, thus reveals that using a parent bus to stand
>> in for a device isn't actually correct. I only posted that horrible hack
>> patch to prove the point that having a child node to represent the
>> actual device is indeed sufficient to make of_dma_configure() work
>> correctly for PCI masters as-is (modulo the other issues).
>>
>>> of course if you talk
>>>> from iommu perspective, all the master are same for IOMMU
>>
>> I don't understand what you mean by that. There's nothing about IOMMUs
>> here, it's purely about parsing DT properties correctly.
>>
>>>> but the original intention of the patch is to try to solve 2 problems.
>>>> please refer to https://lkml.org/lkml/2017/3/29/10
>>
>> One patch should not solve two separate problems anyway. Taking a step
>> back, there are at least 3 things that this discussion has brought up:
>>
>> 1) The way in which we call of_dma_configure() for PCI devices causes
>> the "dma-ranges" property on PCI host controllers to be ignored.
>>
>> 2) of_dma_get_range() only considers the first entry in any "dma-ranges"
>> property.
>>
>> 3) When of_dma_configure() does set a DMA mask, there is nothing on
>> arm64 and other architectures to prevent drivers overriding that with a
>> wider mask later.
>>
>> Those are 3 separate problems, to solve with 3 or more separate patches,
>> and I have deliberately put the second and third to one side for the
>> moment. This patch fixes problem 1.
>>
>>>> 1) expose generic API for pci world clients to configure their
>>>> dma-ranges. right now there is none.
>>>> 2) same API can be used by IOMMU to derive dma_mask.
>>>>
>>>> while the current patch posted to handle dma-ranges for both memory
>>>> mapped and pci devices, which I think is overdoing.
>>
>> No, of_dma_configure() handles the "dma-ranges" property as it is
>> defined in the DT spec to describe the mapping between a child bus
>> address space and a parent bus address space. Whether those
>> memory-mapped parent and child buses are PCI, ISA, AMBA, HyperTransport,
>> or anything else is irrelevant other than for the encoding of the
>> address specifiers. All this patch does is sort out the cases where we
>> have a real device node to start at, from the cases where we don't and
>> so start directly at the device's parent bus node instead.
>>
>>>> besides we have different configuration of dma-ranges based on iommu
>>>> is enabled or not enabled.
>>
>> That doesn't sound right, unless you mean the firmware actually programs
>> the host controller's AXI bridge differently for system configurations
>> where the IOMMU is expected to be used or not? (and even then, I don't
>> really see why it would be necessary to do that...)
>>
>>>> #define PCIE_DMA_RANGES dma-ranges = <0x43000000 0x00 0x80000000 0x00
>>>> 0x80000000 0x00 0x80000000 \
>>>> 0x43000000 0x08 0x00000000 0x08
>>>> 0x00000000 0x08 0x00000000 \
>>>> 0x43000000 0x80 0x00000000 0x80
>>>> 0x00000000 0x40 0x00000000>;
>>>> Not sure if this patch will consider above dma-ranges.
>>>>
>>>> my suggestion is to leave existing of_dma_get_range as is, and have
>>>> new function for pci world as discussed in
>>>> please refer to https://lkml.org/lkml/2017/3/29/10
>>
>> And then we keep adding new functions to do the exact same thing for
>> every other discoverable bus type whose bridge is be described in DT? I
>> fail to see how that is in any way better than simply fixing the
>> existing code to work as it was intended to.
>>
>> of_dma_get_ranges() uses of_translate_dma_address() just the same way as
>> existing PowerPC PCI code does, which further disproves your assertion
>> that parsing PCI addresses is somehow special - it's really only a
>> matter of getting the right number of address cells in order to to read
>> a child address to give to of_translate_dma_address() in the first
>> place. Incidentally, I now notice that the proposed
>> of_pci_get_dma_ranges() is incomplete as it doesn't use
>> of_translate_dma_address() or otherwise traverse upwards through the
>> dma-ranges of any further parent buses.
>>
>>>>
>>>> Regards,
>>>> Oza.
>>>
>>> also I see that, in case of multiple ranges of_dma_get_range doesnt handle that.
>>> and also it is not meant to handle.
>>
>> Yes, the existing code doesn't handle multiple dma-ranges entries,
>> because nobody's had the need to implement that so far, and this patch
>> does not change that because it's fixing a separate problem.
>>
>> Now, of course of_dma_get_range() *should* be capable of handling
>> multiple entries regardless of this patch, and I'm going to write *that*
>> patch right now (it's going to be a case of adding a handful of lines
>> which probably won't even conflict with this one at all). If we had a
>> bunch of different range parsing functions, we'd then have to duplicate
>> the equivalent logic across all of them, which is clearly undesirable
>> when it can easily be avoided altogether.
>>
>> Robin.
>>
>>> so with this patch will return wrong size and hence wrong dma_mask.
>>> having said, I think it is better to separate pci world dma-ranges
>>> function on of_pci.c
>>>
>>> for which my discussion with Rob already, (same thread)
>>> https://lkml.org/lkml/2017/3/29/10
>>> Waiting for Rob's viewpoint on this.
>>>
>>>
>>> Regards,
>>> Oza.
>>>
>>
>
> In my opinion NAKing to this, because
>
> 1) some reasons already mentioned in https://lkml.org/lkml/2017/3/29/10
>
> 2) also of_dma_get_range is supposed to handle traditional dma-ranges
> (not pci one)
>
> 3) we need separate function for pci users such as iproc or rcar SOCs
> to have their dma-ranges parsed,
> which can be extended later for e.g. pci flags have some meanings.
>
> besides of_dma_configure is written to pass only single out parameter
> (..., *dma_addr, *size)
> handling multiple ranges here, and passing only one range out is not desirable.
>
> also you would not like to handle pci flags (the first portion of DT
> entry) in this function if required in future.
>
> this new function will be similar to of_pci_get_host_bridge_resources
> https://lkml.org/lkml/2017/3/29/10
> which I am writing/improving right now..
>
>
> Regards,
> Oza.
Hi Robin,
Gentle request to have a look at following approach and patch.
[RFC PATCH 2/2] of/pci: call pci specific dma-ranges instead of memory-mapped.
[RFC PATCH 1/2] of/pci: implement inbound dma-ranges for PCI
I have tested this on our platform, with and without iommu, and seems to work.
of course it requires your "in discussion" iommu dma_mask" changes to work.
which I believe you will take it ahead. so I have removed all the
iommu related changes now.
and this addresses purely pci world now.
let me know your view on this.
Regards,
Oza.
^ permalink raw reply
* Re: [RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask
From: Oza Oza @ 2017-03-30 10:14 UTC (permalink / raw)
To: Rob Herring
Cc: Joerg Roedel, Robin Murphy, Linux IOMMU,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com
In-Reply-To: <CAL_JsqLvvc75Z_bk46vQpMJGBiFv1mnEfTRJyNwAboHDyYGYAw@mail.gmail.com>
On Tue, Mar 28, 2017 at 7:43 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Mar 28, 2017 at 12:27 AM, Oza Oza <oza.oza@broadcom.com> wrote:
>> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep <oza.oza@broadcom.com> wrote:
>>>> it is possible that PCI device supports 64-bit DMA addressing,
>>>> and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
>>>> however PCI host bridge may have limitations on the inbound
>>>> transaction addressing. As an example, consider NVME SSD device
>>>> connected to iproc-PCIe controller.
>>>>
>>>> Currently, the IOMMU DMA ops only considers PCI device dma_mask
>>>> when allocating an IOVA. This is particularly problematic on
>>>> ARM/ARM64 SOCs where the IOMMU (i.e. SMMU) translates IOVA to
>>>> PA for in-bound transactions only after PCI Host has forwarded
>>>> these transactions on SOC IO bus. This means on such ARM/ARM64
>>>> SOCs the IOVA of in-bound transactions has to honor the addressing
>>>> restrictions of the PCI Host.
>>>>
>>>> current pcie frmework and of framework integration assumes dma-ranges
>>>> in a way where memory-mapped devices define their dma-ranges.
>>>> dma-ranges: (child-bus-address, parent-bus-address, length).
>>>>
>>>> but iproc based SOCs and even Rcar based SOCs has PCI world dma-ranges.
>>>> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
>>>
>>> If you implement a common function, then I expect to see other users
>>> converted to use it. There's also PCI hosts in arch/powerpc that parse
>>> dma-ranges.
>>
>> the common function should be similar to what
>> of_pci_get_host_bridge_resources is doing right now.
>> it parses ranges property right now.
>>
>> the new function would look look following.
>>
>> of_pci_get_dma_ranges(struct device_node *dev, struct list_head *resources)
>> where resources would return the dma-ranges.
>>
>> but right now if you see the patch, of_dma_configure calls the new
>> function, which actually returns the largest possible size.
>> so this new function has to be generic in a way where other PCI hosts
>> can use it. but certainly iproc(Broadcom SOC) , rcar based SOCs can
>> use it for sure.
>>
>> although having powerpc using it; is a separate exercise, since I do
>> not have any access to other PCI hosts such as powerpc. but we can
>> workout with them on thsi forum if required.
>
> You don't need h/w. You can analyze what parts are common, write
> patches to convert to common implementation, and build test. The PPC
> and rcar folks can test on h/w.
>
> Rob
Hi Rob,
I have addressed your comment and made generic function.
Gentle request to have a look at following approach and patch.
[RFC PATCH 2/2] of/pci: call pci specific dma-ranges instead of memory-mapped.
[RFC PATCH 1/2] of/pci: implement inbound dma-ranges for PCI
I have tested this on our platform, with and without iommu, and seems to work.
let me know your view on this.
Regards,
Oza.
^ permalink raw reply
* Re: [PATCH 0/2] mtd: spi-nor: add stm32 qspi driver
From: Marek Vasut @ 2017-03-30 10:15 UTC (permalink / raw)
To: Ludovic BARRE, Cyrille Pitchen, Cyrille Pitchen
Cc: Boris Brezillon, Alexandre Torgue,
devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris,
David Woodhouse
In-Reply-To: <d1c2f0a9-302d-ea7c-5d1b-ad32b9950ed4-qxv4g6HH51o@public.gmane.org>
On 03/30/2017 09:31 AM, Ludovic BARRE wrote:
> hi Cyrille
>
> I see your patch series
>
> [PATCH v5 0/6] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories
>
> No problem, I rebase my V2 onto your patch
I still didn't review that, so it might take a bit until it hits
mainline. I think the stm32 stuff looks pretty OK, so we can take that
before the SFDP stuff, no?
--
Best regards,
Marek Vasut
--
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/2] mtd: spi-nor: add driver for STM32 quad spi flash controller
From: Marek Vasut @ 2017-03-30 10:17 UTC (permalink / raw)
To: Ludovic BARRE, Cyrille Pitchen
Cc: Boris Brezillon, Alexandre Torgue, devicetree, Richard Weinberger,
linux-kernel, Rob Herring, linux-mtd, Brian Norris,
David Woodhouse
In-Reply-To: <d785a279-362c-3693-d318-08ef43af7ad4@st.com>
On 03/29/2017 06:38 PM, Ludovic BARRE wrote:
>
>
> On 03/29/2017 03:57 PM, Marek Vasut wrote:
>> On 03/29/2017 03:35 PM, Ludovic BARRE wrote:
>>
>> [...]
>>
>>>>>>> + writel_relaxed(CR_PRESC(presc) | CR_FTHRES(3) | CR_TCEN |
>>>>>>> CR_SSHIFT
>>>>>>> + | CR_EN, qspi->io_base + QUADSPI_CR);
>>>>>>> +
>>>>>>> + /* a minimum fsize must be set to sent the command id */
>>>>>>> + flash->fsize = 25;
>>>>>> I don't understand why this is needed and the comment doesn't make
>>>>>> sense. Please fix.
>>>>> fsize field defines the size of external memory.
>>>> What external memory ? Unclear
>>> oops, fsize field defined the size of "flash memory" in stm32 qspi
>>> controller.
>> Errr, now I am totally lost :) Is that some internal SPI NOR ? Shouldn't
>> the size be coming from DT or something ?
>>
>>> Number of bytes in Flash memory = 2 ^[FSIZE+1].
>>> To sent a nor cmd this field must be set (hardware issue),
>>> but before "spi_nor_scan" the size of flash nor is not know.
>>> So I set a temporary value (workaround).
>> Is it needed before the scan ?
> yes it's needed before scan (fix a "stm32 qspi controller" issue)
>
> sorry, I try to reformulate:
>
> The nor flash (external component like micron n25q128a13
> or spansion s25fl512s ...) is connected to stm32 by classic
> spi-nor interface cs, clock and 1/2/4 IO lines.
>
> the stm32 microprocessor has a dedicated controller to
> manage spi-nor interface, it's stm32 qspi.
>
> In stm32 qspi controller there is a register with fsize field
> which define the size of nor flash (n25q128a13 or s25fl512s...).
>
> fsize can't be null, else the stm32 qspi controller doesn't send
> spi-nor command. it's "stm32 qspi controller" issue.
>
> Before the "spi_nor_scan" the size of nor flash (n25q128a13
> or s25fl512s...) is not know. So we set a temporary value just
> to discover the nor flash with "spi_nor_scan". After we can
> set the right value (mtd->size) in fsize.
I see, now it makes sense. Such a beefy comment would be nice :)
--
Best regards,
Marek Vasut
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Sjoerd Simons @ 2017-03-30 10:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Simon Horman, Magnus Damm
Cc: Yoshihiro Shimoda, Kuninori Morimoto, Laurent Pinchart,
Wolfram Sang, Rob Herring, Mark Rutland,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490362665-4422-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series adds preliminary support for Renesas Salvator-X
> development boards equipped with revision ES2.0 of the R-Car H3 Soc.
>
> - Patch 1 adds support for the R-Car H3 ES2.0 Soc,
> While this patch is safe as-is, as it doesn't affect any existing
> setups, it's probably a bit premature to apply it.
> - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0.
> This patch does affect existing development setups, as it changes
> the
> name of the DTB for Salvator-X boards equipped with ES1.x SoCs.
> Given most developers have access to ES1.x only, this patch must
> not be
> applied yet.
Would it make more sense to add a new r8a7795-es2.dtsi and keep the
current dtsi for es1? Having to load different device-trees based on
which kernel is used would be rather nasty.
--
Sjoerd Simons
Collabora Ltd.
--
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 v6 00/39] i.MX Media Driver
From: Russell King - ARM Linux @ 2017-03-30 11:02 UTC (permalink / raw)
To: Steve Longerbeam
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, nick-gcszYUEDH4VrovVCs/uTlw,
markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A, sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
pavel-+ZI9xUNit7I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490661656-10318-1-git-send-email-steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
This fails at step 1. The removal of the frame interval support now
means my setup script fails when trying to set the frame interval on
the camera:
Enumerating pads and links
Setting up format SRGGB8_1X8 816x616 on pad imx219 0-0010/0
Format set: SRGGB8_1X8 816x616
Setting up frame interval 1/25 on pad imx219 0-0010/0
Frame interval set: 1/25
Setting up format SRGGB8_1X8 816x616 on pad imx6-mipi-csi2/0
Format set: SRGGB8_1X8 816x616
Setting up frame interval 1/25 on pad imx6-mipi-csi2/0
Unable to set frame interval: Inappropriate ioctl for device (-25)Unable to setup formats: Inappropriate ioctl for device (25)
This is because media-ctl tries to propagate it from the imx219 source
pad to the csi2 sink pad, and the csi2 now fails that ioctl.
This makes media-ctl return a failure code, which means that it's not
possible for a script to determine whether the failure was due to the
camera setup or something else. So, we have to assume that the
whole command failed.
This is completely broken, and I'm even more convinced that those
arguing for this behaviour really have not thought it through well
enough before demanding that this code was removed.
As far as I'm concerned, the end result is completely broken and
unusable. I'm going to be merging the frame interval support back
into my test tree, because that's the only sane thing to do.
If v4l2 people want to object to having frame interval support present
for all subdevs, then _they_ need to make sure that the rest of their
software conforms to what they're telling people to do.
--
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/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-03-30 11:13 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring,
Mark Rutland, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <1490870898.3471.3.camel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Hi Sjoerd,
On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons
<sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote:
>> This patch series adds preliminary support for Renesas Salvator-X
>> development boards equipped with revision ES2.0 of the R-Car H3 Soc.
>>
>> - Patch 1 adds support for the R-Car H3 ES2.0 Soc,
>> While this patch is safe as-is, as it doesn't affect any existing
>> setups, it's probably a bit premature to apply it.
>> - Patch 2 adds support for Salvator-X boards with R-Car H3 ES2.0.
>> This patch does affect existing development setups, as it changes
>> the
>> name of the DTB for Salvator-X boards equipped with ES1.x SoCs.
>> Given most developers have access to ES1.x only, this patch must
>> not be
>> applied yet.
>
> Would it make more sense to add a new r8a7795-es2.dtsi and keep the
> current dtsi for es1? Having to load different device-trees based on
> which kernel is used would be rather nasty.
We definitely considered that option.
However, we concluded that in the end, we want to mainly support production
SoCs. Hence the default files should represent the production version.
Using a preproduction SoC can be considered a special case, and thus needs
a file with a special esX ID in its name.
We do realize this can cause some inconveniences during the transition period,
when most developers don't have access to ES2.0 SoCs yet, or have mixed
environments of ES1.x and ES2.0.
Of course you can keep on using the current DTB (binary) on your H3 ES1.x
boards, as long as you don't need to use devices not yet described in that DTB.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
* [PATCHv4 25/29] drm/omap: displays: panel-dpi: Support for handling backlight devices
From: Tomi Valkeinen @ 2017-03-30 11:15 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Laurent Pinchart
Cc: Jyri Sarha, Peter Ujfalusi, Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490872529-23084-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
From: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
The associated backlight device can be configured via DT by providing the
phandle to the device.
If the backlight device is configured, the driver can manage the backligt
along with the panel's power state, iow it can turn on the backlight when
the panel is enabled and turn it off when the panel is disabled.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
.../bindings/display/panel/panel-dpi.txt | 3 ++
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 37 ++++++++++++++++++++--
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
index d4add13e592d..6b203bc4d932 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
@@ -9,6 +9,7 @@ Optional properties:
- enable-gpios: panel enable gpio
- reset-gpios: GPIO to control the RESET pin
- vcc-supply: phandle of regulator that will be used to enable power to the display
+- backlight: phandle of the backlight device
Required nodes:
- "panel-timing" containing video timings
@@ -22,6 +23,8 @@ lcd0: display@0 {
compatible = "samsung,lte430wq-f0c", "panel-dpi";
label = "lcd";
+ backlight = <&backlight>;
+
port {
lcd_in: endpoint {
remote-endpoint = <&dpi_out>;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index 38003208d9ca..04ce8c5f2954 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -16,6 +16,7 @@
#include <linux/of.h>
#include <linux/of_gpio.h>
#include <linux/regulator/consumer.h>
+#include <linux/backlight.h>
#include <video/omap-panel-data.h>
#include <video/of_display_timing.h>
@@ -30,6 +31,8 @@ struct panel_drv_data {
struct videomode vm;
+ struct backlight_device *backlight;
+
/* used for non-DT boot, to be removed */
int backlight_gpio;
@@ -97,6 +100,11 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
if (gpio_is_valid(ddata->backlight_gpio))
gpio_set_value_cansleep(ddata->backlight_gpio, 1);
+ if (ddata->backlight) {
+ ddata->backlight->props.power = FB_BLANK_UNBLANK;
+ backlight_update_status(ddata->backlight);
+ }
+
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
return 0;
@@ -113,6 +121,11 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
if (gpio_is_valid(ddata->backlight_gpio))
gpio_set_value_cansleep(ddata->backlight_gpio, 0);
+ if (ddata->backlight) {
+ ddata->backlight->props.power = FB_BLANK_POWERDOWN;
+ backlight_update_status(ddata->backlight);
+ }
+
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
regulator_disable(ddata->vcc_supply);
@@ -209,6 +222,7 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct device_node *node = pdev->dev.of_node;
+ struct device_node *bl_node;
struct omap_dss_device *in;
int r;
struct display_timing timing;
@@ -236,10 +250,19 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
ddata->backlight_gpio = -ENOENT;
+ bl_node = of_parse_phandle(node, "backlight", 0);
+ if (bl_node) {
+ ddata->backlight = of_find_backlight_by_node(bl_node);
+ of_node_put(bl_node);
+
+ if (!ddata->backlight)
+ return -EPROBE_DEFER;
+ }
+
r = of_get_display_timing(node, "panel-timing", &timing);
if (r) {
dev_err(&pdev->dev, "failed to get video timing\n");
- return r;
+ goto error_free_backlight;
}
videomode_from_timing(&timing, &ddata->vm);
@@ -247,12 +270,19 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(&pdev->dev, "failed to find video source\n");
- return PTR_ERR(in);
+ r = PTR_ERR(in);
+ goto error_free_backlight;
}
ddata->in = in;
return 0;
+
+error_free_backlight:
+ if (ddata->backlight)
+ put_device(&ddata->backlight->dev);
+
+ return r;
}
static int panel_dpi_probe(struct platform_device *pdev)
@@ -321,6 +351,9 @@ static int __exit panel_dpi_remove(struct platform_device *pdev)
omap_dss_put_device(in);
+ if (ddata->backlight)
+ put_device(&ddata->backlight->dev);
+
return 0;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/3] pinctrl: Add bindings for ARTPEC-6 pinmux
From: Jesper Nilsson @ 2017-03-30 11:27 UTC (permalink / raw)
To: Jesper Nilsson, Lars Persson, Niklas Cassel, Linus Walleij,
Rob Herring, Mark Rutland, Greg Kroah-Hartman, David S. Miller,
Geert Uytterhoeven, Mauro Carvalho Chehab,
linux-arm-kernel-VrBV9hrLPhE, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Add the bindings for the pinmux functions in the
ARTPEC-6 SoC, including bias and drive strength.
Signed-off-by: Jesper Nilsson <jesper.nilsson-VrBV9hrLPhE@public.gmane.org>
---
.../bindings/pinctrl/axis,artpec6-pinctrl.txt | 85 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 86 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
new file mode 100644
index 0000000..47284f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
@@ -0,0 +1,85 @@
+Axis ARTPEC-6 Pin Controller
+
+Required properties:
+- compatible: "axis,artpec6-pinctrl".
+- reg: Should contain the register physical address and length for the pin
+ controller.
+
+A pinctrl node should contain at least one subnode representing the pinctrl
+groups available on the machine. Each subnode will list the mux function
+required and what pin group it will use. Each subnode will also configure the
+drive strength and bias pullup of the pin group. If either of these options is
+not set, its actual value will be unspecified.
+
+
+Required subnode-properties:
+- function: Function to mux.
+- groups: Name of the pin group to use for the function above.
+
+ Available functions and groups (function: group0, group1...):
+ gpio: cpuclkoutgrp0, udlclkoutgrp0, i2c1grp0, i2c2grp0,
+ i2c3grp0, i2s0grp0, i2s1grp0, i2srefclkgrp0, spi0grp0,
+ spi1grp0, pciedebuggrp0, uart0grp0, uart0grp1, uart1grp0,
+ uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0
+ cpuclkout: cpuclkoutgrp0
+ udlclkout: udlclkoutgrp0
+ i2c1: i2c1grp0
+ i2c2: i2c2grp0
+ i2c3: i2c3grp0
+ i2s0: i2s0grp0
+ i2s1: i2s1grp0
+ i2srefclk: i2srefclkgrp0
+ spi0: spi0grp0
+ spi1: spi1grp0
+ pciedebug: pciedebuggrp0
+ uart0: uart0grp0, uart0grp1
+ uart1: uart1grp0
+ uart2: uart2grp0, uart2grp1
+ uart3: uart3grp0
+ uart4: uart4grp0
+ uart5: uart5grp0
+ nand: nandgrp0
+ sdio0: sdio0grp0
+ sdio1: sdio1grp0
+ ethernet: ethernetgrp0
+
+
+Optional subnode-properties (see pinctrl-bindings.txt):
+- drive-strength: 4, 6, 8, 9 mA. For SD and NAND pins, this is for 3.3V VCCQ3.
+- bias-pull-up
+- bias-disable
+
+Examples:
+pinctrl@f801d000 {
+ compatible = "axis,artpec6-pinctrl";
+ reg = <0xf801d000 0x400>;
+
+ pinctrl_uart0: uart0grp {
+ function = "uart0";
+ groups = "uart0grp0";
+ drive-strength = <4>;
+ bias-pull-up;
+ };
+ pinctrl_uart3: uart3grp {
+ function = "uart3";
+ groups = "uart3grp0";
+ };
+};
+uart0: uart@f8036000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xf8036000 0x1000>;
+ interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pll2div24>, <&apb_pclk>;
+ clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+};
+uart3: uart@f8039000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xf8039000 0x1000>;
+ interrupts = <0 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pll2div24>, <&apb_pclk>;
+ clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 1b0a87f..7563bd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1088,6 +1088,7 @@ L: linux-arm-kernel-VrBV9hrLPhE@public.gmane.org
F: arch/arm/mach-artpec
F: arch/arm/boot/dts/artpec6*
F: drivers/clk/axis
+F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
ARM/ASPEED MACHINE SUPPORT
M: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson-VrBV9hrLPhE@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: ARTPEC-6: Add pinctrl configuration
From: Jesper Nilsson @ 2017-03-30 11:33 UTC (permalink / raw)
To: Jesper Nilsson, Lars Persson, Niklas Cassel, Rob Herring,
Mark Rutland, Russell King, linux-arm-kernel-VrBV9hrLPhE,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Enable the pinctrl driver for ARTPEC-6 in the artpec6.dtsi
with all main pinmux functions.
Add pinctrl information to the relevant (uart) nodes.
Signed-off-by: Jesper Nilsson <jesper.nilsson-VrBV9hrLPhE@public.gmane.org>
---
arch/arm/boot/dts/artpec6.dtsi | 87 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
index 767cbe8..471eaee 100644
--- a/arch/arm/boot/dts/artpec6.dtsi
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -181,6 +181,85 @@
status = "disabled";
};
+ pinctrl: pinctrl@f801d000 {
+ compatible = "axis,artpec6-pinctrl";
+ reg = <0xf801d000 0x400>;
+
+ pinctrl_uart0: uart0grp {
+ function = "uart0";
+ groups = "uart0grp1";
+ bias-pull-up;
+ };
+ pinctrl_uart1: uart1grp {
+ function = "uart1";
+ groups = "uart1grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart2: uart2grp {
+ function = "uart2";
+ groups = "uart2grp1";
+ bias-pull-up;
+ };
+ pinctrl_uart3: uart3grp {
+ function = "uart3";
+ groups = "uart3grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart4: uart4grp {
+ function = "uart4";
+ groups = "uart4grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart5: uart5grp {
+ function = "uart5";
+ groups = "uart5grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c1: i2c1grp {
+ function = "i2c1";
+ groups = "i2c1grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c2: i2c2grp {
+ function = "i2c2";
+ groups = "i2c2grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c3: i2c3grp {
+ function = "i2c3";
+ groups = "i2c3grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2s0: i2s0grp {
+ function = "i2s0";
+ groups = "i2s0grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2s1: i2s1grp {
+ function = "i2s1";
+ groups = "i2s1grp0";
+ bias-pull-up;
+ };
+ pinctrl_spi0: spi0grp {
+ function = "spi0";
+ groups = "spi0grp0";
+ bias-pull-up;
+ };
+ pinctrl_spi1: spi1grp {
+ function = "spi1";
+ groups = "spi1grp0";
+ bias-pull-up;
+ };
+ pinctrl_sdio0: sdio0grp {
+ function = "sdio0";
+ groups = "sdio0grp0";
+ };
+ pinctrl_sdio1: sdio1grp {
+ function = "sdio1";
+ groups = "sdio1grp0";
+ };
+ };
+
amba@0 {
compatible = "simple-bus";
#address-cells = <0x1>;
@@ -214,6 +293,8 @@
clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
<&clkctrl ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
status = "disabled";
};
uart1: serial@f8037000 {
@@ -223,6 +304,8 @@
clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
<&clkctrl ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
status = "disabled";
};
uart2: serial@f8038000 {
@@ -232,6 +315,8 @@
clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
<&clkctrl ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
status = "disabled";
};
uart3: serial@f8039000 {
@@ -241,6 +326,8 @@
clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
<&clkctrl ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
status = "disabled";
};
};
--
2.1.4
Reply-To:
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson-VrBV9hrLPhE@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCHv2] phy: cpcap-usb: Add CPCAP PMIC USB support
From: Kishon Vijay Abraham I @ 2017-03-30 11:49 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Michael Scott
In-Reply-To: <20170327150518.GH10760-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Hi Tony,
On Monday 27 March 2017 08:35 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org> [170326 23:27]:
>> On Thursday 23 March 2017 05:16 AM, Tony Lindgren wrote:
>>> +static const struct phy_ops ops = {
>>> + .owner = THIS_MODULE,
>>> +};
>>
>> Given that this phy doesn't have any phy_ops, Is there a reason for registering
>> this phy with the phy framework? Is it because this driver uses the phy_core's
>> pm_runtime feature?
>
> Well there's also an ULPI PHY on CPCAP, but it's not used in the
> motorola-mapphone configuration. I think some other configurations
> use it though, so probably best to keep it.
>
> And yeah, for PM runtime, I was thinking that we can have the
> UART mode be the idle state.
>
>>> +static void cpcap_usb_detect(struct work_struct *work)
>>> +{
>>> + struct cpcap_phy_ddata *ddata;
>>> + struct cpcap_usb_ints_state s;
>>> + bool vbus = false;
>>> + int error;
>>> +
>>> + ddata = container_of(work, struct cpcap_phy_ddata, detect_work.work);
>>> +
>>> + error = cpcap_phy_get_ints_state(ddata, &s);
>>> + if (error)
>>> + return;
>>> +
>>> + /* See also cpcap-charger.c phy_companion for VBUS handling */
>>
>> I think this companion should have ideally used extcon framework. Then we could
>> have used extcon_get_state() here.
>
> OK I'll take a look at that. I'd like to do that as a follow-up
> patches if that's OK with you.
>
> FYI in case you're wondering, there are ADCs on the PMIC available
> via IIO, and the charger is also using IIO framework for VBUS and
> battery voltage. And the VBUS is set up as reverse mode in the
> charger registers and the charging needs to be disabled for VBUS.
>
> I guess Ideally the VBUS would be just a regulator from Linux point
> of view that also allows negative current :)
>
>>> + ddata->vusb = devm_regulator_get(&pdev->dev, "vusb");
>>> + if (IS_ERR(ddata->vusb))
>>> + return PTR_ERR(ddata->vusb);
>>> +
>>> + error = regulator_enable(ddata->vusb);
>>> + if (error)
>>> + return error;
>>
>> Maybe we should create power_on ops and do regulator enable there?
>
> This regulator is also needed for the UART mode, so it would have
> to be disabled conditionally based on maybe a module parameter.
> But yeah thanks for the pointer I did not even realize you have
> power_on ops :)
>
> Seems this can be also done when implementing PM runtime handling.
> If you want some of these changes done for the initial patch,
> please let me know.
I think it's better we get extcon stuff in the initial patch so that we don't
have to maintain some piece of code for legacy dt. Others can be added later.
Thanks
Kishon
--
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/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Sjoerd Simons @ 2017-03-30 11:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring,
Mark Rutland, Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Daniel Stone, Kevin Hilman
In-Reply-To: <CAMuHMdV+=pNpFO7H3J0=JM1BnXtm4t=Q+1bx=R+f9=JxvJZT_Q@mail.gmail.com>
On Thu, 2017-03-30 at 13:13 +0200, Geert Uytterhoeven wrote:
> Hi Sjoerd,
>
> On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons
> <sjoerd.simons@collabora.co.uk> wrote:
> > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote:
> > > This patch series adds preliminary support for Renesas Salvator-X
> > > development boards equipped with revision ES2.0 of the R-Car H3
> > > Soc.
> > >
> > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc,
> > > While this patch is safe as-is, as it doesn't affect any
> > > existing
> > > setups, it's probably a bit premature to apply it.
> > > - Patch 2 adds support for Salvator-X boards with R-Car H3
> > > ES2.0.
> > > This patch does affect existing development setups, as it
> > > changes
> > > the
> > > name of the DTB for Salvator-X boards equipped with ES1.x
> > > SoCs.
> > > Given most developers have access to ES1.x only, this patch
> > > must
> > > not be
> > > applied yet.
> >
> > Would it make more sense to add a new r8a7795-es2.dtsi and keep the
> > current dtsi for es1? Having to load different device-trees based
> > on
> > which kernel is used would be rather nasty.
>
> We definitely considered that option.
> However, we concluded that in the end, we want to mainly support
> production
> SoCs. Hence the default files should represent the production
> version.
> Using a preproduction SoC can be considered a special case, and thus
> needs
> a file with a special esX ID in its name.
The problem is that even though they are pre-production, these are out
there and in active use, e.g. kernelci is at least doing automated
testing on one of those in Kevins lab and should be an additional
soonish in the Collabora lab.
And for developers it'll be extra fun if halfway through a bisect the
dts name changes..
Having a es2 in your dtb name might be a bit quirky, but it's really
just a name without other meaning :).
> We do realize this can cause some inconveniences during the
> transition period,
> when most developers don't have access to ES2.0 SoCs yet, or have
> mixed
> environments of ES1.x and ES2.0.
Heh yeah, i'd expect we'd have a mixed environment for quite a while
given these boards are a bit too expensive to just throw in the trash..
> Of course you can keep on using the current DTB (binary) on your H3
> ES1.x
> boards, as long as you don't need to use devices not yet described in
> that DTB.
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linu
> x-m68k.org
>
> In personal conversations with technical people, I call myself a
> hacker. But
> when I'm talking to journalists I just say "programmer" or something
> like that.
> -- Linus Torvalds
--
Sjoerd Simons
Collabora Ltd.
^ permalink raw reply
* Re: [PATCH] ARM: dts: da850: move spi0_cs3_pin pinconf node
From: Sekhar Nori @ 2017-03-30 11:52 UTC (permalink / raw)
To: David Lechner, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Kevin Hilman, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490663566-23062-1-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Tuesday 28 March 2017 06:42 AM, David Lechner wrote:
> This moves the spi0_cs3_pin pinconf node from the LEGO EV3 file to the
> common DA850 include file. This node is applicable to any board, and
> therefore belongs in the common file.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Applied for v4.12
Thanks,
Sekhar
--
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] pinctrl: Add bindings for ARTPEC-6 pinmux
From: Linus Walleij @ 2017-03-30 11:53 UTC (permalink / raw)
To: Jesper Nilsson
Cc: Jesper Nilsson, Lars Persson, Niklas Cassel, Rob Herring,
Mark Rutland, Greg Kroah-Hartman, David S. Miller,
Geert Uytterhoeven, Mauro Carvalho Chehab, linux-arm-kernel,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170330112744.GE29118@axis.com>
On Thu, Mar 30, 2017 at 1:27 PM, Jesper Nilsson <jesper.nilsson@axis.com> wrote:
> Add the bindings for the pinmux functions in the
> ARTPEC-6 SoC, including bias and drive strength.
>
> Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Pretty much ideal bindings. Just giving some slack for the DT
maintainers to look at it first.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH/RFC v2 0/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-03-30 12:08 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Laurent Pinchart, Wolfram Sang, Rob Herring,
Mark Rutland, Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Daniel Stone, Kevin Hilman
In-Reply-To: <1490874625.3471.6.camel@collabora.co.uk>
Hi Sjoerd,
On Thu, Mar 30, 2017 at 1:50 PM, Sjoerd Simons
<sjoerd.simons@collabora.co.uk> wrote:
> On Thu, 2017-03-30 at 13:13 +0200, Geert Uytterhoeven wrote:
>> On Thu, Mar 30, 2017 at 12:48 PM, Sjoerd Simons
>> <sjoerd.simons@collabora.co.uk> wrote:
>> > On Fri, 2017-03-24 at 14:37 +0100, Geert Uytterhoeven wrote:
>> > > This patch series adds preliminary support for Renesas Salvator-X
>> > > development boards equipped with revision ES2.0 of the R-Car H3
>> > > Soc.
>> > >
>> > > - Patch 1 adds support for the R-Car H3 ES2.0 Soc,
>> > > While this patch is safe as-is, as it doesn't affect any
>> > > existing
>> > > setups, it's probably a bit premature to apply it.
>> > > - Patch 2 adds support for Salvator-X boards with R-Car H3
>> > > ES2.0.
>> > > This patch does affect existing development setups, as it
>> > > changes
>> > > the
>> > > name of the DTB for Salvator-X boards equipped with ES1.x
>> > > SoCs.
>> > > Given most developers have access to ES1.x only, this patch
>> > > must
>> > > not be
>> > > applied yet.
>> >
>> > Would it make more sense to add a new r8a7795-es2.dtsi and keep the
>> > current dtsi for es1? Having to load different device-trees based
>> > on
>> > which kernel is used would be rather nasty.
>>
>> We definitely considered that option.
>> However, we concluded that in the end, we want to mainly support
>> production
>> SoCs. Hence the default files should represent the production
>> version.
>> Using a preproduction SoC can be considered a special case, and thus
>> needs
>> a file with a special esX ID in its name.
>
> The problem is that even though they are pre-production, these are out
> there and in active use, e.g. kernelci is at least doing automated
> testing on one of those in Kevins lab and should be an additional
> soonish in the Collabora lab.
>
> And for developers it'll be extra fun if halfway through a bisect the
> dts name changes..
>
> Having a es2 in your dtb name might be a bit quirky, but it's really
> just a name without other meaning :).
>
>> We do realize this can cause some inconveniences during the
>> transition period,
>> when most developers don't have access to ES2.0 SoCs yet, or have
>> mixed
>> environments of ES1.x and ES2.0.
>
> Heh yeah, i'd expect we'd have a mixed environment for quite a while
> given these boards are a bit too expensive to just throw in the trash..
>
>> Of course you can keep on using the current DTB (binary) on your H3
>> ES1.x
>> boards, as long as you don't need to use devices not yet described in
>> that DTB.
We can keep on discussing this for a while, this is definitely v4.13+ material.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 2/2] PCI: Add tango PCIe host bridge support
From: kbuild test robot @ 2017-03-30 12:09 UTC (permalink / raw)
To: Marc Gonzalez
Cc: kbuild-all, Bjorn Helgaas, Marc Zyngier, Thomas Gleixner,
Robin Murphy, Lorenzo Pieralisi, Liviu Dudau, David Laight,
linux-pci, Linux ARM, Thibaud Cornic, Phuong Nguyen, LKML, DT,
Mason
In-Reply-To: <65114e62-7458-b6f7-327c-f07a5096a452@sigmadesigns.com>
[-- Attachment #1: Type: text/plain, Size: 19079 bytes --]
Hi Marc,
[auto build test ERROR on v4.9-rc8]
[also build test ERROR on next-20170330]
[cannot apply to pci/next]
[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/Marc-Gonzalez/Tango-PCIe-controller-support/20170330-154028
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
In file included from drivers/pci/host/pcie-tango.c:4:0:
>> include/linux/pci-ecam.h:29:19: error: field 'pci_ops' has incomplete type
struct pci_ops pci_ops;
^~~~~~~
>> include/linux/pci-ecam.h:57:39: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
^~~~~~~
>> drivers/pci/host/pcie-tango.c:198:39: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
static int smp8759_config_read(struct pci_bus *bus,
^~~~~~~
drivers/pci/host/pcie-tango.c: In function 'smp8759_config_read':
>> drivers/pci/host/pcie-tango.c:202:37: error: dereferencing pointer to incomplete type 'struct pci_bus'
struct pci_config_window *cfg = bus->sysdata;
^~
>> drivers/pci/host/pcie-tango.c:211:10: error: 'PCIBIOS_FUNC_NOT_SUPPORTED' undeclared (first use in this function)
return PCIBIOS_FUNC_NOT_SUPPORTED; /* Error seems appropriate */
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c:211:10: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/pci/host/pcie-tango.c:219:15: error: 'PCI_BASE_ADDRESS_0' undeclared (first use in this function)
if (where == PCI_BASE_ADDRESS_0 && bus->number == 0) {
^~~~~~~~~~~~~~~~~~
>> drivers/pci/host/pcie-tango.c:221:10: error: 'PCIBIOS_SUCCESSFUL' undeclared (first use in this function)
return PCIBIOS_SUCCESSFUL; /* Should we return error or success? */
^~~~~~~~~~~~~~~~~~
>> drivers/pci/host/pcie-tango.c:233:8: error: implicit declaration of function 'pci_generic_config_read' [-Werror=implicit-function-declaration]
ret = pci_generic_config_read(bus, devfn, where, size, val);
^~~~~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: At top level:
drivers/pci/host/pcie-tango.c:239:40: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
static int smp8759_config_write(struct pci_bus *bus,
^~~~~~~
drivers/pci/host/pcie-tango.c: In function 'smp8759_config_write':
drivers/pci/host/pcie-tango.c:243:37: error: dereferencing pointer to incomplete type 'struct pci_bus'
struct pci_config_window *cfg = bus->sysdata;
^~
>> drivers/pci/host/pcie-tango.c:247:8: error: implicit declaration of function 'pci_generic_config_write' [-Werror=implicit-function-declaration]
ret = pci_generic_config_write(bus, devfn, where, size, val);
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: At top level:
>> drivers/pci/host/pcie-tango.c:256:3: error: field name not in record or union initializer
.map_bus = pci_ecam_map_bus,
^
drivers/pci/host/pcie-tango.c:256:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci/host/pcie-tango.c:257:3: error: field name not in record or union initializer
.read = smp8759_config_read,
^
drivers/pci/host/pcie-tango.c:257:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci/host/pcie-tango.c:258:3: error: field name not in record or union initializer
.write = smp8759_config_write,
^
drivers/pci/host/pcie-tango.c:258:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci/host/pcie-tango.c: In function 'tango_fixup_class':
>> drivers/pci/host/pcie-tango.c:329:5: error: dereferencing pointer to incomplete type 'struct pci_dev'
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
^~
>> drivers/pci/host/pcie-tango.c:329:15: error: 'PCI_CLASS_BRIDGE_PCI' undeclared (first use in this function)
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
^~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: At top level:
>> drivers/pci/host/pcie-tango.c:320:22: error: expected declaration specifiers or '...' before numeric constant
#define VENDOR_SIGMA 0x1105
^
>> drivers/pci/host/pcie-tango.c:331:25: note: in expansion of macro 'VENDOR_SIGMA'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~~~
In file included from include/linux/of.h:22:0,
from include/linux/irqdomain.h:34,
from drivers/pci/host/pcie-tango.c:3:
>> include/linux/mod_devicetable.h:16:20: error: expected declaration specifiers or '...' before '(' token
#define PCI_ANY_ID (~0)
^
>> drivers/pci/host/pcie-tango.c:331:39: note: in expansion of macro 'PCI_ANY_ID'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~
>> drivers/pci/host/pcie-tango.c:331:51: error: expected declaration specifiers or '...' before 'tango_fixup_class'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: In function 'tango_fixup_bar':
>> drivers/pci/host/pcie-tango.c:342:9: error: implicit declaration of function 'pci_write_config_dword' [-Werror=implicit-function-declaration]
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x80000000);
^~~~~~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c:342:37: error: 'PCI_BASE_ADDRESS_0' undeclared (first use in this function)
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x80000000);
^~~~~~~~~~~~~~~~~~
drivers/pci/host/pcie-tango.c: At top level:
>> drivers/pci/host/pcie-tango.c:320:22: error: expected declaration specifiers or '...' before numeric constant
#define VENDOR_SIGMA 0x1105
^
drivers/pci/host/pcie-tango.c:344:25: note: in expansion of macro 'VENDOR_SIGMA'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~~~
In file included from include/linux/of.h:22:0,
from include/linux/irqdomain.h:34,
from drivers/pci/host/pcie-tango.c:3:
>> include/linux/mod_devicetable.h:16:20: error: expected declaration specifiers or '...' before '(' token
#define PCI_ANY_ID (~0)
^
drivers/pci/host/pcie-tango.c:344:39: note: in expansion of macro 'PCI_ANY_ID'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~
--
In file included from drivers/pci//host/pcie-tango.c:4:0:
>> include/linux/pci-ecam.h:29:19: error: field 'pci_ops' has incomplete type
struct pci_ops pci_ops;
^~~~~~~
>> include/linux/pci-ecam.h:57:39: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
^~~~~~~
drivers/pci//host/pcie-tango.c:198:39: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
static int smp8759_config_read(struct pci_bus *bus,
^~~~~~~
drivers/pci//host/pcie-tango.c: In function 'smp8759_config_read':
drivers/pci//host/pcie-tango.c:202:37: error: dereferencing pointer to incomplete type 'struct pci_bus'
struct pci_config_window *cfg = bus->sysdata;
^~
drivers/pci//host/pcie-tango.c:211:10: error: 'PCIBIOS_FUNC_NOT_SUPPORTED' undeclared (first use in this function)
return PCIBIOS_FUNC_NOT_SUPPORTED; /* Error seems appropriate */
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:211:10: note: each undeclared identifier is reported only once for each function it appears in
drivers/pci//host/pcie-tango.c:219:15: error: 'PCI_BASE_ADDRESS_0' undeclared (first use in this function)
if (where == PCI_BASE_ADDRESS_0 && bus->number == 0) {
^~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:221:10: error: 'PCIBIOS_SUCCESSFUL' undeclared (first use in this function)
return PCIBIOS_SUCCESSFUL; /* Should we return error or success? */
^~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:233:8: error: implicit declaration of function 'pci_generic_config_read' [-Werror=implicit-function-declaration]
ret = pci_generic_config_read(bus, devfn, where, size, val);
^~~~~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: At top level:
drivers/pci//host/pcie-tango.c:239:40: warning: 'struct pci_bus' declared inside parameter list will not be visible outside of this definition or declaration
static int smp8759_config_write(struct pci_bus *bus,
^~~~~~~
drivers/pci//host/pcie-tango.c: In function 'smp8759_config_write':
drivers/pci//host/pcie-tango.c:243:37: error: dereferencing pointer to incomplete type 'struct pci_bus'
struct pci_config_window *cfg = bus->sysdata;
^~
drivers/pci//host/pcie-tango.c:247:8: error: implicit declaration of function 'pci_generic_config_write' [-Werror=implicit-function-declaration]
ret = pci_generic_config_write(bus, devfn, where, size, val);
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: At top level:
drivers/pci//host/pcie-tango.c:256:3: error: field name not in record or union initializer
.map_bus = pci_ecam_map_bus,
^
drivers/pci//host/pcie-tango.c:256:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci//host/pcie-tango.c:257:3: error: field name not in record or union initializer
.read = smp8759_config_read,
^
drivers/pci//host/pcie-tango.c:257:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci//host/pcie-tango.c:258:3: error: field name not in record or union initializer
.write = smp8759_config_write,
^
drivers/pci//host/pcie-tango.c:258:3: note: (near initialization for 'smp8759_ecam_ops.pci_ops')
drivers/pci//host/pcie-tango.c: In function 'tango_fixup_class':
drivers/pci//host/pcie-tango.c:329:5: error: dereferencing pointer to incomplete type 'struct pci_dev'
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
^~
drivers/pci//host/pcie-tango.c:329:15: error: 'PCI_CLASS_BRIDGE_PCI' undeclared (first use in this function)
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
^~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: At top level:
drivers/pci//host/pcie-tango.c:320:22: error: expected declaration specifiers or '...' before numeric constant
#define VENDOR_SIGMA 0x1105
^
drivers/pci//host/pcie-tango.c:331:25: note: in expansion of macro 'VENDOR_SIGMA'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~~~
In file included from include/linux/of.h:22:0,
from include/linux/irqdomain.h:34,
from drivers/pci//host/pcie-tango.c:3:
>> include/linux/mod_devicetable.h:16:20: error: expected declaration specifiers or '...' before '(' token
#define PCI_ANY_ID (~0)
^
drivers/pci//host/pcie-tango.c:331:39: note: in expansion of macro 'PCI_ANY_ID'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~
drivers/pci//host/pcie-tango.c:331:51: error: expected declaration specifiers or '...' before 'tango_fixup_class'
DECLARE_PCI_FIXUP_EARLY(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_class);
^~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: In function 'tango_fixup_bar':
drivers/pci//host/pcie-tango.c:342:9: error: implicit declaration of function 'pci_write_config_dword' [-Werror=implicit-function-declaration]
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x80000000);
^~~~~~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:342:37: error: 'PCI_BASE_ADDRESS_0' undeclared (first use in this function)
pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x80000000);
^~~~~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c: At top level:
drivers/pci//host/pcie-tango.c:320:22: error: expected declaration specifiers or '...' before numeric constant
#define VENDOR_SIGMA 0x1105
^
drivers/pci//host/pcie-tango.c:344:25: note: in expansion of macro 'VENDOR_SIGMA'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~~~
In file included from include/linux/of.h:22:0,
from include/linux/irqdomain.h:34,
from drivers/pci//host/pcie-tango.c:3:
>> include/linux/mod_devicetable.h:16:20: error: expected declaration specifiers or '...' before '(' token
#define PCI_ANY_ID (~0)
^
drivers/pci//host/pcie-tango.c:344:39: note: in expansion of macro 'PCI_ANY_ID'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~
drivers/pci//host/pcie-tango.c:344:51: error: expected declaration specifiers or '...' before 'tango_fixup_bar'
DECLARE_PCI_FIXUP_FINAL(VENDOR_SIGMA, PCI_ANY_ID, tango_fixup_bar);
^~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:340:13: warning: 'tango_fixup_bar' defined but not used [-Wunused-function]
static void tango_fixup_bar(struct pci_dev *dev)
^~~~~~~~~~~~~~~
drivers/pci//host/pcie-tango.c:327:13: warning: 'tango_fixup_class' defined but not used [-Wunused-function]
static void tango_fixup_class(struct pci_dev *dev)
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/pci_ops +29 include/linux/pci-ecam.h
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 23 * struct to hold pci ops and bus shift of the config window
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 24 * for a PCI controller.
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 25 */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 26 struct pci_config_window;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 27 struct pci_ecam_ops {
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 28 unsigned int bus_shift;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 @29 struct pci_ops pci_ops;
5c3d14f7 include/linux/pci-ecam.h Jayachandran C 2016-06-10 30 int (*init)(struct pci_config_window *);
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 31 };
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 32
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 33 /*
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 34 * struct to hold the mappings of a config space window. This
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 35 * is expected to be used as sysdata for PCI controllers that
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 36 * use ECAM.
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 37 */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 38 struct pci_config_window {
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 39 struct resource res;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 40 struct resource busr;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 41 void *priv;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 42 struct pci_ecam_ops *ops;
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 43 union {
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 44 void __iomem *win; /* 64-bit single mapping */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 45 void __iomem **winp; /* 32-bit per-bus mapping */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 46 };
5c3d14f7 include/linux/pci-ecam.h Jayachandran C 2016-06-10 47 struct device *parent;/* ECAM res was from this dev */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 48 };
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 49
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 50 /* create and free pci_config_window */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 51 struct pci_config_window *pci_ecam_create(struct device *dev,
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 52 struct resource *cfgres, struct resource *busr,
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 53 struct pci_ecam_ops *ops);
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 54 void pci_ecam_free(struct pci_config_window *cfg);
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 55
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 56 /* map_bus when ->sysdata is an instance of pci_config_window */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 @57 void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 58 int where);
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 59 /* default ECAM ops */
35ff9477 drivers/pci/ecam.h Jayachandran C 2016-05-10 60 extern struct pci_ecam_ops pci_generic_ecam_ops;
:::::: The code at line 29 was first introduced by commit
:::::: 35ff9477d880986441981010585399c1d7201fee PCI: Provide common functions for ECAM mapping
:::::: TO: Jayachandran C <jchandra@broadcom.com>
:::::: CC: Bjorn Helgaas <bhelgaas@google.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 59492 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH v2 1/2] mfd: retu: Add OF device ID table
From: Rob Herring @ 2017-03-30 12:41 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lee Jones
In-Reply-To: <20170315104958.24919-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Wed, Mar 15, 2017 at 5:49 AM, Javier Martinez Canillas
<javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
> The driver doesn't have a struct of_device_id table but supported devices
> are registered via Device Trees. This is working on the assumption that a
> I2C device registered via OF will always match a legacy I2C device ID and
> that the MODALIAS reported will always be of the form i2c:<device>.
It should also have the OF MODALIAS.
> But this could change in the future so the correct approach is to have a
> OF device ID table if the devices are registered via OF.
I believe this is already the case.
> The compatible strings don't have a vendor prefix because that's how it's
> used currently, and changing this will be a Device Tree ABI break.
How so? These "compatible" strings are not documented, so there is no
ABI. You may have been lucky to get things working using the driver
name as the compatible string.
Rob
--
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: [REPOST PATCH] ARM: dts: imx6qp-nitrogen6_som2: add Quad Plus variant of the SOM
From: Shawn Guo @ 2017-03-30 12:49 UTC (permalink / raw)
To: Gary Bisson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, fabio.estevam-3arQi8VN3Tc,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20170329084523.8065-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
On Wed, Mar 29, 2017 at 10:45:23AM +0200, Gary Bisson wrote:
> https://boundarydevices.com/product/nit6x-som-v2/
>
> Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
Applied, 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: [RESEND PATCH v2 1/2] mfd: retu: Add OF device ID table
From: Javier Martinez Canillas @ 2017-03-30 12:49 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lee Jones
In-Reply-To: <CAL_JsqJTxT1V1Y8Wte4W22UjFcAKUuny5VCFpurwjkPz=hGxVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Rob,
On 03/30/2017 08:41 AM, Rob Herring wrote:
> On Wed, Mar 15, 2017 at 5:49 AM, Javier Martinez Canillas
> <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>> The driver doesn't have a struct of_device_id table but supported devices
>> are registered via Device Trees. This is working on the assumption that a
>> I2C device registered via OF will always match a legacy I2C device ID and
>> that the MODALIAS reported will always be of the form i2c:<device>.
>
> It should also have the OF MODALIAS.
>
Yes, it should but currently it doesn't. This is the .uevent callback for I2C:
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct i2c_client *client = to_i2c_client(dev);
int rc;
rc = acpi_device_uevent_modalias(dev, env);
if (rc != -ENODEV)
return rc;
return add_uevent_var(env, "MODALIAS=%s%s", I2C_MODULE_PREFIX, client->name);
}
>> But this could change in the future so the correct approach is to have a
>> OF device ID table if the devices are registered via OF.
>
> I believe this is already the case.
>
No, in fact the purpose of these patches (and others that I've been posting in
all subsystems) is to make sure that adding proper OF MODALIAS support for I2C
won't cause regressions in existing drivers due not having OF device ID tables.
This is the RFC patch I posted some time ago for I2C core:
https://patchwork.ozlabs.org/patch/388200/
>> The compatible strings don't have a vendor prefix because that's how it's
>> used currently, and changing this will be a Device Tree ABI break.
>
> How so? These "compatible" strings are not documented, so there is no
> ABI. You may have been lucky to get things working using the driver
> name as the compatible string.
>
Yes, it's not documented but I thought that having users meant that it was
already an ABI.
I'm more than happy to change the upstream DTS to add a vendor prefix and
use this also in the drivers.
> Rob
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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/5] ARM: dts: imx7-colibri: use OF graph to describe the display
From: Shawn Guo @ 2017-03-30 13:16 UTC (permalink / raw)
To: Stefan Agner
Cc: kernel, fabio.estevam, robh+dt, mark.rutland, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20170329232113.19078-1-stefan@agner.ch>
On Wed, Mar 29, 2017 at 04:21:09PM -0700, Stefan Agner wrote:
> To make use of the new eLCDIF DRM driver OF graph description is
> required. Describe the display using OF graph nodes.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Applied all, thanks.
^ permalink raw reply
* RE: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header
From: Chris Brandt @ 2017-03-30 13:27 UTC (permalink / raw)
To: Linus Walleij
Cc: Jacopo Mondi, Bjorn Andersson, Geert Uytterhoeven,
Laurent Pinchart, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkda_Gw9vhLqpWw8oOZyZ59nj5j9Q-T5RXVsf0vsxWcjyHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4517 bytes --]
On Thursday, March 30, 2017, Linus Walleij wrote:
> >> > +/*
> >> > + * Pin is bi-directional.
> >> > + * An alternate function that needs both input/output
> >> > +functionalities shall
> >> > + * be configured as bidirectional.
> >> > + * Eg. SDA/SCL pins of an I2c interface.
> >> > + */
> >> > +#define BI_DIR (1 << 3)
> >>
> >> Any specific reason why this should not simply be added to
> >> include/linux/pinctrl/pinconf-generic.h
> >> as PIN_CONFIG_BIDIRECTIONAL and parsed in drivers/pinctrl/pinconf-
> >> generic.c from the (new) DT property "bidirectional" simply?
> >
> > I see your point. It would cut down from every driver out there
> > inventing some new property or config instead of everyone just sharing
> > a fixed set.
> > Maybe someone else out there will end up having a need for a
> > "bidirectional" option.
>
> I was thinking about that one. It is a bit weird electrically, like what
> kind of electronics is really bidirectional?
>
> It seems like a fancy name for open drain/open source, what we call
> "single ended" configuration. (See docs in
> Documentation/gpio/driver.txt)
>
> It would be great if you could check if that is what they mean, actually.
Here is the definition of the register in the hardware manual:
---
54.3.13 Port Bidirection Control Register (PBDCn)
This register enables or disables the input buffer while the output buffer is enabled. When the input buffer is enabled
while the output buffer is enabled, the bidirectional mode is entered, allowing the level of the Pn_m pin to always be read
via the PPRn.PPRnm bit.
---
But...what they don't really tell you is that any peripheral that needs to TX and RX data over a pin needs this set.
In the hardware manual, there is a pretty picture (Figure 54.1 Logical Diagram of Port Control) that shows a detailed logic diagram of the interface between the peripheral bus and the pin pad.
As far as I can tell, the "function mux" portion of this controller only knows how to set a pin as direction=in or direction=out.
So, in the case of I2C where each the SCL and SDA pins needs to be driven and read...it can't do that.
Therefore, there is an additional register to manually enable the input buffer and let the mux enable the output buffer.
So while yes, I2C is open-drain, this is also the case for the data pins for the SDHI. And the MDIO pin from Ethernet. It really has to do with the fact that this pin controller wasn't designed to enable both the input and output buffers at the same time.
The situation is similar for our SWIO_IN and SWIO_OUT flags. For example, to use the SSI sound interface, you have to set the TX signals to "input" (SWIO_IN). Makes sense, right??
I could argue that all of these "FLAGS" settings should have been incorporated in the HW logic of the pin controller...but for whatever reason, the they had to make them separate registers and make SW do it.
So, I could argue that these registers settings are really part of pin muxing, not really user config....and hence belong in the "pinmux" property.
How about this compromise: Instead of BI_DIR, we use "TYPE_I2C", "TYPE_SDDATA", "TYPE_MDIO", "TYPE_LVDS", etc... to describe the 'special' ones. That way it can go back under "pinmux". Like Jacopo said, these register settings are really supposed to be set when you are selecting the pin-mux option.
Of course behind the scenes, it's really:
#define TYPE_I2C BI_DIR
#define TYPE_SDDATA BI_DIR
#define TYPE_SDCMD BI_DIR
#define TYPE_LVDS SWIO_OUT
Examples:
i2c3_pins: i2c3 {
pinmux = <PIN(1, 6) | FUNC_1 | TYPE_I2C>,
<PIN(1, 7) | FUNC_1 | TYPE_I2C>;
};
/* SHDI ch1 on CN1 */
sdhi1_pins: sdhi1 {
/* SHDI ch1 on Port 3 */
pinmux = <PIN(3, 8) | FUNC_7>, /* SDHI1 CD */
<PIN(3, 9) FUNC_7)>, /* SDHI1 WP */
<PIN(3, 10) FUNC_7 | TYPE_SDDATA)>, /* SDHI1 DAT1 */
<PIN(3, 11) FUNC_7 | TYPE_SDDATA)>, /* SDHI1 DAT0 */
<PIN(3, 12) FUNC_7)>, /* SDHI1 CLK */
<PIN(3, 13) FUNC_7 | TYPE_SDCMD)>, /* SDHI1 CMD */
<PIN(3, 14) FUNC_7 | TYPE_SDDATA)>, /* SDHI1 DAT3 */
<PIN(3, 15) FUNC_7 | TYPE_SDDATA)>; /* SDHI1 DAT2 */
};
# Honestly, I have no idea where this pin controller came from. I have not seen it in any other Renesas part (Mitsubishi/Hitachi/NEC).
Chris
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* [PATCH v2] Extend pca9532 device tree support
From: Felix Brack @ 2017-03-30 13:33 UTC (permalink / raw)
To: jacek.anaszewski, rpurdie, pavel, mark.rutland, riku.voipio,
linux-leds, devicetree
Cc: linux-kernel, fb
This patch extends the device tree support for the pca9532 by adding
the leds 'default-state' property.
Changes in v2:
- remove prescaler and pwm configuration by none generic
DT properties
Signed-off-by: Felix Brack <fb@ltec.ch>
---
.../devicetree/bindings/leds/leds-pca9532.txt | 10 +++++++
drivers/leds/leds-pca9532.c | 31 +++++++++++++++++++++-
include/linux/leds-pca9532.h | 4 +--
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-pca9532.txt b/Documentation/devicetree/bindings/leds/leds-pca9532.txt
index 198f3ba..8374075 100644
--- a/Documentation/devicetree/bindings/leds/leds-pca9532.txt
+++ b/Documentation/devicetree/bindings/leds/leds-pca9532.txt
@@ -17,6 +17,8 @@ Optional sub-node properties:
- label: see Documentation/devicetree/bindings/leds/common.txt
- type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE)
- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
+ - default-state: see Documentation/devicetree/bindings/leds/common.txt
+ This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>.
Example:
#include <dt-bindings/leds/leds-pca9532.h>
@@ -33,6 +35,14 @@ Example:
label = "pca:green:power";
type = <PCA9532_TYPE_LED>;
};
+ kernel-booting {
+ type = <PCA9532_TYPE_LED>;
+ default-state = "on";
+ };
+ sys-stat {
+ type = <PCA9532_TYPE_LED>;
+ default-state = "keep"; // don't touch, was set by U-Boot
+ };
};
For more product information please see the link below:
diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
index 06e6310..66ef280 100644
--- a/drivers/leds/leds-pca9532.c
+++ b/drivers/leds/leds-pca9532.c
@@ -254,6 +254,21 @@ static void pca9532_input_work(struct work_struct *work)
mutex_unlock(&data->update_lock);
}
+static enum pca9532_state pca9532_getled(struct pca9532_led *led)
+{
+ struct i2c_client *client = led->client;
+ struct pca9532_data *data = i2c_get_clientdata(client);
+ u8 maxleds = data->chip_info->num_leds;
+ char reg;
+ enum pca9532_state ret;
+
+ mutex_lock(&data->update_lock);
+ reg = i2c_smbus_read_byte_data(client, LED_REG(maxleds, led->id));
+ ret = reg >> LED_NUM(led->id)/2;
+ mutex_unlock(&data->update_lock);
+ return ret;
+}
+
#ifdef CONFIG_LEDS_PCA9532_GPIO
static int pca9532_gpio_request_pin(struct gpio_chip *gc, unsigned offset)
{
@@ -366,7 +381,10 @@ static int pca9532_configure(struct i2c_client *client,
gpios++;
break;
case PCA9532_TYPE_LED:
- led->state = pled->state;
+ if (pled->state == PCA9532_KEEP)
+ led->state = pca9532_getled(led);
+ else
+ led->state = pled->state;
led->name = pled->name;
led->ldev.name = led->name;
led->ldev.default_trigger = pled->default_trigger;
@@ -456,6 +474,7 @@ pca9532_of_populate_pdata(struct device *dev, struct device_node *np)
const struct of_device_id *match;
int devid, maxleds;
int i = 0;
+ const char *state;
match = of_match_device(of_pca9532_leds_match, dev);
if (!match)
@@ -475,6 +494,16 @@ pca9532_of_populate_pdata(struct device *dev, struct device_node *np)
of_property_read_u32(child, "type", &pdata->leds[i].type);
of_property_read_string(child, "linux,default-trigger",
&pdata->leds[i].default_trigger);
+ if (!of_property_read_string(child, "default-state", &state)) {
+ if (!strcmp(state, "on"))
+ pdata->leds[i].state = PCA9532_ON;
+ else if (!strcmp(state, "keep"))
+ pdata->leds[i].state = PCA9532_KEEP;
+ else if (!strcmp(state, "pwm0"))
+ pdata->leds[i].state = PCA9532_PWM0;
+ else if (!strcmp(state, "pwm1"))
+ pdata->leds[i].state = PCA9532_PWM1;
+ }
if (++i >= maxleds) {
of_node_put(child);
break;
diff --git a/include/linux/leds-pca9532.h b/include/linux/leds-pca9532.h
index d215b45..a327b1aa 100644
--- a/include/linux/leds-pca9532.h
+++ b/include/linux/leds-pca9532.h
@@ -22,7 +22,8 @@ enum pca9532_state {
PCA9532_OFF = 0x0,
PCA9532_ON = 0x1,
PCA9532_PWM0 = 0x2,
- PCA9532_PWM1 = 0x3
+ PCA9532_PWM1 = 0x3,
+ PCA9532_KEEP = 0xff
};
struct pca9532_led {
@@ -44,4 +45,3 @@ struct pca9532_platform_data {
};
#endif /* __LINUX_PCA9532_H */
-
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v5 6/9] coresight: add support for CPU debug module
From: Leo Yan @ 2017-03-30 13:51 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Mike Leach, Mathieu Poirier, Jonathan Corbet, Rob Herring,
Mark Rutland, Wei Xu, Catalin Marinas, Will Deacon, Andy Gross,
David Brown, Michael Turquette, Stephen Boyd, Guodong Xu,
John Stultz, linux-doc, linux-kernel, devicetree,
linux-arm-kernel, linux-arm-msm, linux-soc, linux-clk,
Sudeep Holla <sudeep.holla>
In-Reply-To: <a9078a4e-152e-01ae-8750-1396da2bc623@arm.com>
On Thu, Mar 30, 2017 at 10:00:30AM +0100, Suzuki K Poulose wrote:
[...]
> Leo,
>
> Also, it would be good to restore the PRCR register back to the original state
> after we read the registers (if we changed them). I am exploring ways to make
> use of this feature on demand (e.g, tie it to sysrq-t or sysrq-l) and not just
> at panic time. So it would be good to have the state restored to not affect the
> normal functioning even after dumping the registers.
Got it. Will take care for this.
Thanks,
Leo Yan
> PS: I have a small hack to hook this into a sysrq-x at runtime, but on a second thought
> it is better not to consume the key and rather tie it to something which already exist,
> as mentioned above.
>
> Thanks
> Suzuki
^ permalink raw reply
* Re: [PATCH v3 14/37] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Boris Brezillon @ 2017-03-30 14:02 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-15-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On Thu, 30 Mar 2017 15:46:00 +0900
Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> 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, 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).
For PCI users, you explicitly set the NAND_ECC_MAXIMIZE flag, so it
shouldn't be a problem (you're still backward compatible).
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>
> Changes in v3: None
> Changes in v2:
> - Add available values in the binding document
>
> Documentation/devicetree/bindings/mtd/denali-nand.txt | 6 ++++++
> drivers/mtd/nand/denali.c | 18 ++++++++++++++++--
> drivers/mtd/nand/denali_pci.c | 1 +
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
> index 25313c7..647618e 100644
> --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
> @@ -11,6 +11,12 @@ Optional properties:
> - nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
> 512 for "altr,socfpga-denali-nand"
> see nand.txt for details.
> + - nand-ecc-strength: see nand.txt for details. Available values are:
> + 8, 15 for "altr,socfpga-denali-nand"
> + - nand-ecc-maximize: see nand.txt for details
> +
> +Note:
> +Either nand-ecc-strength or nand-ecc-maximize should be specified.
>
> The device tree may optionally contain sub-nodes describing partitions of the
> address space. See partition.txt for more detail.
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index ce87b95..2f796e3 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1641,9 +1641,23 @@ int denali_init(struct denali_nand_info *denali)
> goto failed_req_irq;
> }
>
> - ret = denali_set_max_ecc_strength(denali);
> - if (ret)
> + if (!chip->ecc.strength && !(chip->ecc.options & NAND_ECC_MAXIMIZE)) {
> + dev_info(denali->dev,
> + "No ECC strength strategy is specified. Maximizing ECC strength\n");
> + chip->ecc.options |= NAND_ECC_MAXIMIZE;
> + }
> +
> + if (chip->ecc.options & NAND_ECC_MAXIMIZE) {
> + ret = denali_set_max_ecc_strength(denali);
> + if (ret)
> + goto failed_req_irq;
> + } else if (!(denali->ecc_strength_avail & BIT(chip->ecc.strength))) {
> + dev_err(denali->dev,
> + "ECC strength %d is not supported on this controller.\n",
> + chip->ecc.strength);
> + ret = -EINVAL;
> goto failed_req_irq;
> + }
>
> chip->ecc.bytes = denali_calc_ecc_bytes(chip->ecc.size,
> chip->ecc.strength);
> diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
> index a1ee9f8..a39682a5 100644
> --- a/drivers/mtd/nand/denali_pci.c
> +++ b/drivers/mtd/nand/denali_pci.c
> @@ -87,6 +87,7 @@ static int denali_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
>
> denali->ecc_strength_avail = BIT(15) | BIT(8);
> denali->caps |= DENALI_CAP_ECC_SIZE_512;
> + denali->nand.ecc.options |= NAND_ECC_MAXIMIZE;
>
> ret = denali_init(denali);
> 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: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations
From: Robin Murphy @ 2017-03-30 14:09 UTC (permalink / raw)
To: roy.pledge-3arQi8VN3Tc, oss-fOR+EgIDQEHk1uMJSBkQmQ,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: madalin.bucur-3arQi8VN3Tc
In-Reply-To: <1490822037-6752-3-git-send-email-roy.pledge-3arQi8VN3Tc@public.gmane.org>
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.
> Signed-off-by: Roy Pledge <roy.pledge-3arQi8VN3Tc@public.gmane.org>
> ---
> drivers/soc/fsl/qbman/qman_ccsr.c | 119 +++++++++++++++++++++-----------------
> drivers/soc/fsl/qbman/qman_priv.h | 4 +-
> drivers/soc/fsl/qbman/qman_test.h | 2 -
> 3 files changed, 68 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c b/drivers/soc/fsl/qbman/qman_ccsr.c
> index 90bc40c..35c59ca 100644
> --- a/drivers/soc/fsl/qbman/qman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
> @@ -400,63 +400,19 @@ static int qm_init_pfdr(struct device *dev, u32 pfdr_start, u32 num)
> return -ENODEV;
> }
>
> -/*
> - * Ideally we would use the DMA API to turn rmem->base into a DMA address
> - * (especially if iommu translations ever get involved). Unfortunately, the
> - * DMA API currently does not allow mapping anything that is not backed with
> - * a struct page.
> - */
> +/* QMan needs two global memory areas initialized at boot time:
> + 1) FQD: Frame Queue Descriptors used to manage frame queues
> + 2) PFDR: Packed Frame Queue Descriptor Records used to store frames
> + Both areas are reserved using the device tree reserved memory framework
> + and the addresses and sizes are initialized when the QMan device is probed */
> static dma_addr_t fqd_a, pfdr_a;
> static size_t fqd_sz, pfdr_sz;
>
> -static int qman_fqd(struct reserved_mem *rmem)
> -{
> - fqd_a = rmem->base;
> - fqd_sz = rmem->size;
> -
> - WARN_ON(!(fqd_a && fqd_sz));
> -
> - return 0;
> -}
> -RESERVEDMEM_OF_DECLARE(qman_fqd, "fsl,qman-fqd", qman_fqd);
> -
> -static int qman_pfdr(struct reserved_mem *rmem)
> -{
> - pfdr_a = rmem->base;
> - pfdr_sz = rmem->size;
> -
> - WARN_ON(!(pfdr_a && pfdr_sz));
> -
> - return 0;
> -}
> -RESERVEDMEM_OF_DECLARE(qman_pfdr, "fsl,qman-pfdr", qman_pfdr);
> -
I notice that patch #1 isn't removing the equivalent bman_fbpr() handler
and declaration as here - is that deliberate or just an oversight?
> static unsigned int qm_get_fqid_maxcnt(void)
> {
> return fqd_sz / 64;
> }
>
> -/*
> - * Flush this memory range from data cache so that QMAN originated
> - * transactions for this memory region could be marked non-coherent.
> - */
> -static int zero_priv_mem(struct device *dev, struct device_node *node,
> - phys_addr_t addr, size_t sz)
> -{
> - /* map as cacheable, non-guarded */
> - void __iomem *tmpp = ioremap_prot(addr, sz, 0);
> -
> - if (!tmpp)
> - return -ENOMEM;
> -
> - memset_io(tmpp, 0, sz);
> - flush_dcache_range((unsigned long)tmpp,
> - (unsigned long)tmpp + sz);
> - iounmap(tmpp);
> -
> - return 0;
> -}
> -
> static void log_edata_bits(struct device *dev, u32 bit_count)
> {
> u32 i, j, mask = 0xffffffff;
> @@ -687,11 +643,12 @@ static int qman_resource_init(struct device *dev)
> static int fsl_qman_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *node = dev->of_node;
> + struct device_node *mem_node, *node = dev->of_node;
> struct resource *res;
> int ret, err_irq;
> u16 id;
> u8 major, minor;
> + u64 size;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> @@ -727,10 +684,66 @@ static int fsl_qman_probe(struct platform_device *pdev)
> qm_channel_caam = QMAN_CHANNEL_CAAM_REV3;
> }
>
> - ret = zero_priv_mem(dev, node, fqd_a, fqd_sz);
> - WARN_ON(ret);
> - if (ret)
> + /* Order of memory regions is assumed as FQD followed by PFDR
> + in order to ensure allocations from the correct regions the
> + driver initializes then allocates each piece in order */
> +
> + ret = of_reserved_mem_device_init_by_idx(dev, dev->of_node, 0);
> + if (ret) {
> + dev_err(dev, "of_reserved_mem_device_init_by_idx(0) failed 0x%x\n",
> + ret);
> + return -ENODEV;
> + }
> + mem_node = of_parse_phandle(dev->of_node, "memory-region", 0);
> + if (mem_node) {
> + ret = of_property_read_u64(mem_node, "size", &size);
> + if (ret) {
> + dev_err(dev, "FQD: of_address_to_resource fails 0x%x\n", ret);
Nit: of_address_to_resource?
> + return -ENODEV;
> + }
> + fqd_sz = size;
> + } else {
> + dev_err(dev, "No memory-region found for FQD\n");
> + return -ENODEV;
> + }
> + if (!dma_zalloc_coherent(dev, fqd_sz, &fqd_a, 0)) {
> + dev_err(dev, "Alloc FQD memory failed\n");
> + return -ENODEV;
> + }
Between here, below, and patch #1, it looks like this "init, get size,
alloc" pattern could be nicely factored out into a common helper function.
> +
> + dev_info(dev, "Allocated FQD 0x%llx 0x%zx\n", fqd_a, fqd_sz);
> +
> + /* Disassociate the FQD reseverd memory area from the device because
> + a device can only have one DMA memory area. This should be fine
> + since the memory is allocated and initalized and only ever accessed
> + by the QMan device from now on */
Typos: reserved, initialized.
> + of_reserved_mem_device_release(dev);
I see the driver does not implement a .remove method where you would
otherwise be technically expected to balance the allocation with a
dma_free_coherent(), so I think this trick is acceptable. If anyone
wants to change that in future, it wouldn't seem unreasonable to extend
the core code to handle multiple areas per device (and at worst, I guess
you could deviously juggle dev->dma_mem around the DMA API calls).
Other than those first few nits, and any possible PPC-specific angles
I'm not aware of, I think the series is looking good!
Thanks,
Robin.
> +
> + /* Setup PFDR memory */
> + ret = of_reserved_mem_device_init_by_idx(dev, dev->of_node, 1);
> + if (ret) {
> + dev_err(dev, "of_reserved_mem_device_init(1) failed 0x%x\n",
> + ret);
> + return -ENODEV;
> + }
> + mem_node = of_parse_phandle(dev->of_node, "memory-region", 1);
> + if (mem_node) {
> + ret = of_property_read_u64(mem_node, "size", &size);
> + if (ret) {
> + dev_err(dev, "PFDR: of_address_to_resource fails 0x%x\n", ret);
> + return -ENODEV;
> + }
> + pfdr_sz = size;
> + } else {
> + dev_err(dev, "No memory-region found for PFDR\n");
> + return -ENODEV;
> + }
> + if (!dma_zalloc_coherent(dev, pfdr_sz, &pfdr_a, 0)) {
> + dev_err(dev, "Alloc PFDR Failed size 0x%zx\n", pfdr_sz);
> return -ENODEV;
> + }
> +
> + dev_info(dev, "Allocated PFDR 0x%llx 0x%zx\n", pfdr_a, pfdr_sz);
>
> ret = qman_init_ccsr(dev);
> if (ret) {
> diff --git a/drivers/soc/fsl/qbman/qman_priv.h b/drivers/soc/fsl/qbman/qman_priv.h
> index 22725bd..1e998ea5 100644
> --- a/drivers/soc/fsl/qbman/qman_priv.h
> +++ b/drivers/soc/fsl/qbman/qman_priv.h
> @@ -28,12 +28,12 @@
> * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> */
>
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> #include "dpaa_sys.h"
>
> #include <soc/fsl/qman.h>
> #include <linux/iommu.h>
> +#include <linux/dma-contiguous.h>
> +#include <linux/of_address.h>
>
> #if defined(CONFIG_FSL_PAMU)
> #include <asm/fsl_pamu_stash.h>
> diff --git a/drivers/soc/fsl/qbman/qman_test.h b/drivers/soc/fsl/qbman/qman_test.h
> index d5f8cb2..41bdbc48 100644
> --- a/drivers/soc/fsl/qbman/qman_test.h
> +++ b/drivers/soc/fsl/qbman/qman_test.h
> @@ -30,7 +30,5 @@
>
> #include "qman_priv.h"
>
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
> int qman_test_stash(void);
> int qman_test_api(void);
>
--
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