* [PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735 charger
From: Paul Kocialkowski @ 2016-09-21 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <90828c8d-e46d-0956-d6b3-e88fc90f3049@nvidia.com>
Le mercredi 21 septembre 2016 ? 08:30 +0100, Jon Hunter a ?crit?:
> On 20/09/16 19:02, Paul Kocialkowski wrote:
> >
> > * PGP Signed by an unknown key
> >
> > Le mardi 20 septembre 2016 ? 18:40 +0100, Jon Hunter a ?crit :
> > >
> > > On 28/08/16 18:32, Paul Kocialkowski wrote:
> > > >
> > > > ?
> > > > Nyan boards come with an embedded controller that controls when to
> > > > enable and disable the charge. Thus, it should not be left up to the
> > > > kernel to handle that.
> > > > ?
> > > > Using the ti,external-control property allows specifying this use-case.
> > > ?
> > > So the bq24735 is populated under the EC's 'i2c-tunnel' property which
> > > is there to specifically interface it's child devices to the host. So I
> > > am a bit confused why this is expose to the host if it should not be used?
> >
> > Well, it needs to access the information in the read-only registers provided
> > by
> > the chip, which is allowed by the setup in place that you described.
>
> Is this to expose the current state to the kernel so we can monitor the
> battery state?
Yes, that is correct.
> > However, the EC has its internal state machine that decides when to start
> > charging, etc and so should be the only one to write registers, to avoid
> > conflicts.
> >
> > >
> > > Again you may right and I did find the original series [0] for this
> > > which specifically references the Acer Chromebook that needs this.
> > > However, I am not sure why this was never populated? Is there any other
> > > history here?
> >
> > I am also confused about why it wasn't applied earlier. However, the cros
> > kernel
> > is using the very same scheme.
>
> Do you have a reference?
Sure thing, there's a similar commit for the dts[0] and one for the driver[1]
(which was already merged in mainline).
> > > What is the actual problem you see without making this change?
> >
> > There is a risk of conflict (even though it's probably not that
> > significant),
> > given the low variety of possible cases here. The idea is simply to say that
> > the
> > EC is in charge and to let it do its job without interfering.
> >
> > >
> > > The original series states ...
> > > ?
> > > "On Acer Chromebook 13 (CB5-311) this module fails to load if the
> > > charger is not inserted, and will error when it is removed."
> >
> > I'm confused about that comment. At this point (and with this patch), it
> > works
> > normally.
>
> Ok, I think Thierry prefers to only apply fixes for problems that can be
> reproduced. Is there a simple way to check the battery status and
> charging status via say the sysfs? If I can test that this has no
> negative impact may be it is ok.
Sure, this is exported at: /sys/class/power_supply/bq24735 at 5-0009
Also, note that the power-supply next branch[2] has some more fixes for the
bq24735 driver.
Cheers,
[0]:?https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e25a91f87af41e29012a4e2dd7a9ab725efd308e
[1]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6b34e53d506b44f911d0fd246ccdc8b4e942e4ae
[2]: https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/log/?h=for-next
--
Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/be9788f1/attachment.sig>
^ permalink raw reply
* Re: [v12, 7/8] base: soc: introduce soc_device_match() interface
From: Alexander Shiyan @ 2016-09-21 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-8-git-send-email-yangbo.lu@nxp.com>
>?????, 21 ???????? 2016, 9:57 +03:00 ?? Yangbo Lu <yangbo.lu@nxp.com>:
>
>From: Arnd Bergmann < arnd@arndb.de >
>
>We keep running into cases where device drivers want to know the exact
>version of the a SoC they are currently running on. In the past, this has
>usually been done through a vendor specific API that can be called by a
>driver, or by directly accessing some kind of version register that is
>not part of the device itself but that belongs to a global register area
>of the chip.
...
>+const struct soc_device_attribute *soc_device_match(
>+const struct soc_device_attribute *matches)
>+{
>+int ret = 0;
>+
>+if (!matches)
>+return NULL;
>+
>+while (!ret) {
>+if (!(matches->machine || matches->family ||
>+ matches->revision || matches->soc_id))
>+break;
>+ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
>+ soc_device_match_one);
>+if (!ret)
>+matches++;
So, what happen if next "matches" (after increment) will be NULL?
I think you should use while(matches) at the start of this procedure.
---
^ permalink raw reply
* [PATCH] spi: atmel: use managed resource for gpio chip select
From: Nicolas Ferre @ 2016-09-21 7:55 UTC (permalink / raw)
To: linux-arm-kernel
Use the managed gpio CS pin request so that we avoid having trouble
in the cleanup code.
In fact, if module was configured with DT, cleanup code released
invalid pin. Since resource wasn't freed, module cannot be reinserted.
Reported-by: Alexander Morozov <linux@meltdown.ru>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/spi/spi-atmel.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 8feac599e9ab..4e3f2345844a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1248,7 +1248,8 @@ static int atmel_spi_setup(struct spi_device *spi)
return -ENOMEM;
if (as->use_cs_gpios) {
- ret = gpio_request(npcs_pin, dev_name(&spi->dev));
+ ret = devm_gpio_request(&spi->dev,
+ npcs_pin, dev_name(&spi->dev));
if (ret) {
kfree(asd);
return ret;
@@ -1471,13 +1472,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
static void atmel_spi_cleanup(struct spi_device *spi)
{
struct atmel_spi_device *asd = spi->controller_state;
- unsigned gpio = (unsigned long) spi->controller_data;
if (!asd)
return;
spi->controller_state = NULL;
- gpio_free(gpio);
kfree(asd);
}
--
2.9.0
^ permalink raw reply related
* [PATCH v6 2/4] drivers: irqchip: Add STM32 external interrupts support
From: Maxime Coquelin @ 2016-09-21 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609210949150.5573@nanos>
2016-09-21 9:50 GMT+02:00 Thomas Gleixner <tglx@linutronix.de>:
> On Wed, 21 Sep 2016, Alexandre Torgue wrote:
>
>> Hi Thomas,
>>
>> On 09/20/2016 10:16 PM, Thomas Gleixner wrote:
>> > Alexandre,
>> >
>> > On Tue, 20 Sep 2016, Alexandre TORGUE wrote:
>> >
>> > > The STM32 external interrupt controller consists of edge detectors that
>> > > generate interrupts requests or wake-up events.
>> > >
>> > > Each line can be independently configured as interrupt or wake-up source,
>> > > and triggers either on rising, falling or both edges. Each line can also
>> > > be masked independently.
>> > >
>> > > Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> > > Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>> >
>> > That all looks very reasonable now. The only remaining question is your SOB
>> > chain. Who is the author of these patches? You or Maxime? If it's Maxime,
>> > then the changelog misses a From: tag. If it's you then Maximes SOB is
>> > bogus.
>>
>> Actually Maxime wrote the main part of this driver and sent version 1 and 2 of
>> the series. After Linus W. reviews, rework was required to use hierarchical
>> domain. According to Maxime, I coded the rework (adaptation to hierarchical
>> domain) and sent other version of the series.
>
> So I replace Maximes SOB with Originally-by: Does that apply to all four
> patches?
Yes, that's fine.
Alex did a lot of rework on this series, he deserves the SoB.
Thanks,
Maxime
^ permalink raw reply
* [PATCH 1/4] ARM: tegra: nyan: Use proper IRQ type definitions
From: Jon Hunter @ 2016-09-21 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474395289.1215.20.camel@paulk.fr>
On 20/09/16 19:14, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 ? 18:15 +0100, Jon Hunter a ?crit :
>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>
>>> This switches a few interrupt definitions that were using
>>> GPIO_ACTIVE_HIGH as IRQ type, which is invalid.
>>
>> May be you are right, but this does not describe why this is invalid.
>> Can you elaborate?
>
> GPIO_ACTIVE_HIGH is simply not the right kind of define to use in the
> "interrupts" devicetree property. Values provided there are understood as
> IRQ_TYPE_ defines.
Right, but you are changing the type as GPIO_ACTIVE_HIGH = 0 and
IRQ_TYPE_EDGE_FALLING = 2 and there is no comment about why this has
been changed. It might be correct, but you need to explain it.
Jon
--
nvpublic
^ permalink raw reply
* ftrace function_graph causes system crash
From: Bean Huo (beanhuo) @ 2016-09-21 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920100716.131d3647@gandalf.local.home>
> From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org]
> On Behalf Of Steven Rostedt
> Sent: Dienstag, 20. September 2016 16:07
> To: Bean Huo (beanhuo) <beanhuo@micron.com>
> Cc: Zoltan Szubbocsev (zszubbocsev) <zszubbocsev@micron.com>;
> catalin.marinas at arm.com; will.deacon at arm.com; rfi at lists.rocketboards.org;
> linux-kernel at vger.kernel.org; mingo at redhat.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: ftrace function_graph causes system crash
>
> On Tue, 20 Sep 2016 13:10:39 +0000
> "Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
>
> > Hi, all
> > I just use ftrace to do some latency study, found that function_graph
> > can not Work, as long as enable it, will cause kernel panic. I searched this
> online.
> > Found that there are also some cause the same as mine. I am a newer of
> ftrace.
> > I want to know who know what root cause? Here is some partial log:
> >
> >
>
> Can you do a function bisect to find what function this is.
>
> This script is used to help find functions that are being traced by function tracer
> or function graph tracing that causes the machine to reboot, hang, or crash.
> Here's the steps to take.
>
> First, determine if function graph is working with a single function:
>
> # cd /sys/kernel/debug/tracing
> # echo schedule > set_ftrace_filter
> # echo function_graph > current_tracer
>
> If this works, then we know that something is being traced that shouldn't be.
>
> # echo nop > current_tracer
>
> # cat available_filter_functions > ~/full-file # ftrace-bisect ~/full-file ~/test-file
> ~/non-test-file # cat ~/test-file > set_ftrace_filter
>
> *** Note *** this will take several minutes. Setting multiple functions is an
> O(n^2) operation, and we are dealing with thousands of functions.
> So go have coffee, talk with your coworkers, read facebook. And eventually,
> this operation will end.
>
> # echo function_graph > current_tracer
>
> If it crashes, we know that ~/test-file has a bad function.
>
> Reboot back to test kernel.
>
> # cd /sys/kernel/debug/tracing
> # mv ~/test-file ~/full-file
>
> If it didn't crash.
>
> # echo nop > current_tracer
> # mv ~/non-test-file ~/full-file
>
> Get rid of the other test file from previous run (or save them off somewhere.
> # rm -f ~/test-file ~/non-test-file
>
> And start again:
>
> # ftrace-bisect ~/full-file ~/test-file ~/non-test-file
>
> The good thing is, because this cuts the number of functions in ~/test-file by half,
> the cat of it into set_ftrace_filter takes half as long each iteration, so don't talk
> so much at the water cooler the second time.
>
> Eventually, if you did this correctly, you will get down to the problem function,
> and all we need to do is to notrace it.
>
> The way to figure out if the problem function is bad, just do:
>
> # echo <problem-function> > set_ftrace_notrace # echo > set_ftrace_filter #
> echo function_graph > current_tracer
>
> And if it doesn't crash, we are done.
>
> -- Steve
Hi, Steve
Thanks very much! This is a very useful trace tool, I now know the problem function,
It is gt_counter_read, if not trace this function, ftrace function_graph work well.
Do you know now how to deeply debug and trace which line is wrong through Ftrace?
--Bean
^ permalink raw reply
* [PATCH v6 2/4] drivers: irqchip: Add STM32 external interrupts support
From: Thomas Gleixner @ 2016-09-21 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f7875786-9b5e-075a-59c8-cd32fb1c4583@st.com>
On Wed, 21 Sep 2016, Alexandre Torgue wrote:
> Hi Thomas,
>
> On 09/20/2016 10:16 PM, Thomas Gleixner wrote:
> > Alexandre,
> >
> > On Tue, 20 Sep 2016, Alexandre TORGUE wrote:
> >
> > > The STM32 external interrupt controller consists of edge detectors that
> > > generate interrupts requests or wake-up events.
> > >
> > > Each line can be independently configured as interrupt or wake-up source,
> > > and triggers either on rising, falling or both edges. Each line can also
> > > be masked independently.
> > >
> > > Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> > > Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
> >
> > That all looks very reasonable now. The only remaining question is your SOB
> > chain. Who is the author of these patches? You or Maxime? If it's Maxime,
> > then the changelog misses a From: tag. If it's you then Maximes SOB is
> > bogus.
>
> Actually Maxime wrote the main part of this driver and sent version 1 and 2 of
> the series. After Linus W. reviews, rework was required to use hierarchical
> domain. According to Maxime, I coded the rework (adaptation to hierarchical
> domain) and sent other version of the series.
So I replace Maximes SOB with Originally-by: Does that apply to all four
patches?
Thanks,
tglx
^ permalink raw reply
* [PATCH v6 2/4] drivers: irqchip: Add STM32 external interrupts support
From: Alexandre Torgue @ 2016-09-21 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1609202214460.5476@nanos>
Hi Thomas,
On 09/20/2016 10:16 PM, Thomas Gleixner wrote:
> Alexandre,
>
> On Tue, 20 Sep 2016, Alexandre TORGUE wrote:
>
>> The STM32 external interrupt controller consists of edge detectors that
>> generate interrupts requests or wake-up events.
>>
>> Each line can be independently configured as interrupt or wake-up source,
>> and triggers either on rising, falling or both edges. Each line can also
>> be masked independently.
>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>
> That all looks very reasonable now. The only remaining question is your SOB
> chain. Who is the author of these patches? You or Maxime? If it's Maxime,
> then the changelog misses a From: tag. If it's you then Maximes SOB is
> bogus.
Actually Maxime wrote the main part of this driver and sent version 1
and 2 of the series. After Linus W. reviews, rework was required to use
hierarchical domain. According to Maxime, I coded the rework (adaptation
to hierarchical domain) and sent other version of the series.
Regards
Alex
>
> Thanks,
>
> tglx
>
>
^ permalink raw reply
* [PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection
From: Paul Kocialkowski @ 2016-09-21 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6501341f-e14c-4876-dcb7-60a33b7621c4@nvidia.com>
Le mercredi 21 septembre 2016 ? 08:34 +0100, Jon Hunter a ?crit?:
> On 20/09/16 19:02, Paul Kocialkowski wrote:
> >
> > * PGP Signed by an unknown key
> >
> > Le mardi 20 septembre 2016 ? 18:56 +0100, Jon Hunter a ?crit :
> > >
> > > On 20/09/16 18:53, Paul Kocialkowski wrote:
> > > >
> > > >
> > > > >
> > > > > Old Signed by an unknown key
> > > >
> > > > Le mardi 20 septembre 2016 ? 18:41 +0100, Jon Hunter a ?crit :
> > > > >
> > > > >
> > > > > On 28/08/16 18:32, Paul Kocialkowski wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Depthcharge (the payload used with cros devices) will attempt to
> > > > > > detect
> > > > > > boards using their revision. This includes all the known revisions
> > > > > > for
> > > > > > the nyan-big board so that the dtb can be selected preferably.
> > > > >
> > > > > May be I am missing something here, but for the mainline there is only
> > > > > one dtb available and so why is this needed for the mainline?
> > > >
> > > > There is indeed a single dts in mainline, but depthcharge will use the
> > > > revision
> > > > to match the compatible string (e.g. it will look for google,nyan-big-
> > > > rev5,
> > > > not
> > > > google,nyan-big), so we need to list them all in that single dts.
> > > > Otherwise,
> > > > depthcharge will fall back to the default config, which may or may not
> > > > be
> > > > suitable for nyan.
> > >
> > > Is tegra124-nyan-big.dtb not the default?
> >
> > You can't expect that to always be the case. The image format allows many
> > different dts to be provided, so I could easily build with
> > multi_v7_defconfig
> > and have various dts for various devices in the same image, and just select
> > a
> > random one as default.
>
> Really? Sounds odd. I was hoping that tegra124-nyan-big.dtb would be a
> catch all.
Yes, the image format (FIT) allows specifying multiple dtb and zImage
combinations in the same image[0].
See depthcharge[|1] for how the "compatible" property is being matched against.
> > Here, default is really a fallback, the right one is expected to be detected
> > by
> > this mechanism. And it really doesn't hurt to provide that information for
> > proper detection.
> >
> > Note that this is done with many other cros devices in mainline (such as
> > rk3288
> > veyrons).
>
> Yes, I guess the same is true for the tegra210-smaug and we do define
> all the revs for that one. May be extend the changelog comment to say
> what may happen without this change and the problem that this is fixing.
Allright, will do!
Thanks
[0]:?http://www.denx.de/wiki/pub/U-Boot/Documentation/multi_image_booting_scenarios.pdf
[1]:?https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/master/src/boot/fit.c#39
--
Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/d16c5577/attachment.sig>
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: AKASHI Takahiro @ 2016-09-21 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E00CDC.70403@arm.com>
On Mon, Sep 19, 2016 at 05:05:48PM +0100, James Morse wrote:
> On 16/09/16 21:17, Ard Biesheuvel wrote:
> > On 16 September 2016 at 17:04, James Morse <james.morse@arm.com> wrote:
> >> Mark, Ard, how does/will reserved-memory work on an APCI only system?
> >
> > It works by accident, at the moment. We used to ignore both
> > /memreserve/s and the /reserved-memory node, but due to some unrelated
> > refactoring, we ended up honouring the reserved-memory node when
> > booting via UEFI
>
> Okay, so kdump probably shouldn't rely on this behaviour...
>
> For an acpi-only system, we could get reserve_crashkernel() to copy the uefi
> memory map into the reserved region, changing the region types for existing
> kernel memory to EfiReservedMemoryType (for example) and fixing up the reserved
> region boundaries.
>
> This second memory map could then be added alongside the real one in the
> DT/chosen, and used in preference the second time we go through uefi_init() in
> the crash kernel.
Do we need add this map as the second one?
Why not replace "linux,uefi-mmap-start" in a new blob?
> kexec-tools would still need to keep the '/reserved-memory' node for non-uefi
> systems.
Yeah, but if we go in our own way on UEFI/ACPI systems, we may want to
go in a DT-specific way, like PPC does, on DT systems.
(That is, "linux,usable-memory" in memory nodes.)
Thanks,
-Takahiro AKASHI
> Doing this doesn't depend on userspace, and means the uefi memory map is still
> the one and only true source of memory layout information. If fixing it like
> this is valid I don't think it should block kdump.
>
> ... I will think about this some more before trying to put it together.
>
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH 5/9] dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP configs
From: Peter Ujfalusi @ 2016-09-21 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921035326.GF2609@localhost>
On 09/21/16 06:53, Vinod Koul wrote:
> On Wed, Sep 21, 2016 at 09:21:32AM +0530, Vinod Koul wrote:
>> On Fri, Sep 16, 2016 at 11:33:20AM +0300, Peter Ujfalusi wrote:
>>> The DMAengine driver for omap-dma use three function calls from the
>>> plat-omap legacy driver. When the DMAengine driver is built when ARCH_OMAP
>>> is not set, the compilation will fail due to missing symbols.
>>> Add empty inline functions to allow the DMAengine driver to be compiled
>>> with COMPILE_TEST.
>>
>> Peter,
>>
>> This should be before you enable COMPILE_TEST otherwise build will break!
>
> Ah never mind, you have three drivers in this series so I think this is fine
> before the omap one :)
Yep, patch 1-4 is for eDMA, patch 5-6 is for omap-dma and the remaining is for
ti-dma-crossbar.
I wanted to have them separate (including when I enable the COMPILE_TEST) so
we can revert easily if needed.
If I move the 'enable COMPILE_TEST' patches at the end of the series, I think
I will still have them as separate as they are enabling the test for three
different driver.
--
P?ter
^ permalink raw reply
* [PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection
From: Jon Hunter @ 2016-09-21 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474394544.1215.13.camel@paulk.fr>
On 20/09/16 19:02, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 ? 18:56 +0100, Jon Hunter a ?crit :
>> On 20/09/16 18:53, Paul Kocialkowski wrote:
>>>
>>>> Old Signed by an unknown key
>>>
>>> Le mardi 20 septembre 2016 ? 18:41 +0100, Jon Hunter a ?crit :
>>>>
>>>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>>>
>>>>>
>>>>> Depthcharge (the payload used with cros devices) will attempt to detect
>>>>> boards using their revision. This includes all the known revisions for
>>>>> the nyan-big board so that the dtb can be selected preferably.
>>>>
>>>> May be I am missing something here, but for the mainline there is only
>>>> one dtb available and so why is this needed for the mainline?
>>>
>>> There is indeed a single dts in mainline, but depthcharge will use the
>>> revision
>>> to match the compatible string (e.g. it will look for google,nyan-big-rev5,
>>> not
>>> google,nyan-big), so we need to list them all in that single dts. Otherwise,
>>> depthcharge will fall back to the default config, which may or may not be
>>> suitable for nyan.
>>
>> Is tegra124-nyan-big.dtb not the default?
>
> You can't expect that to always be the case. The image format allows many
> different dts to be provided, so I could easily build with multi_v7_defconfig
> and have various dts for various devices in the same image, and just select a
> random one as default.
Really? Sounds odd. I was hoping that tegra124-nyan-big.dtb would be a
catch all.
> Here, default is really a fallback, the right one is expected to be detected by
> this mechanism. And it really doesn't hurt to provide that information for
> proper detection.
>
> Note that this is done with many other cros devices in mainline (such as rk3288
> veyrons).
Yes, I guess the same is true for the tegra210-smaug and we do define
all the revs for that one. May be extend the changelog comment to say
what may happen without this change and the problem that this is fixing.
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v26 0/7] arm64: add kdump support
From: AKASHI Takahiro @ 2016-09-21 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC1812.6040906@arm.com>
James,
On Fri, Sep 16, 2016 at 05:04:34PM +0100, James Morse wrote:
> (Cc: Ard),
>
> Mark, Ard, how does/will reserved-memory work on an APCI only system?
>
>
> On 07/09/16 05:29, AKASHI Takahiro wrote:
> > v26-specific note: After a comment from Rob[0], an idea of adding
> > "linux,usable-memory-range" was dropped. Instead, an existing
> > "reserved-memory" node will be used to limit usable memory ranges
> > on crash dump kernel.
> > This works not only on UEFI/ACPI systems but also on DT-only systems,
> > but if he really insists on using DT-specific "usable-memory" property,
> > I will post additional patches for kexec-tools. Those would be
> > redundant, though.
> > Even in that case, the kernel will not have to be changed.
>
> Some narrative on how the old memory ranges get reserved, as there is no longer
> any code in the series doing this, (which is pretty neat!):
Thank you for detailed explanation :)
I was wondering whether I should have added such kind of description,
but it was nothing but, I believed, a "normal" DT behavior.
> kexec-tools parses the list of memory ranges in /proc/iomem, and adds a node to
> the /reserved-memory for System RAM ranges that don't cover the crash kernel.
> Decompiling the crash-kernel DT from Seattle, it looks roughly like this:
>
> reserved-memory {
> ranges;
> #size-cells = <0x2>;
> #address-cells = <0x2>;
>
> crash_dump at 83ffe50000 {
> no-map;
> reg = <0x83 0xffe50000 0x0 0x1b0000>;
> };
>
> [ ... ]
> };
>
>
> 'no-map' means its doing the same thing to memblock as
> 'linux,usable-memory-range' did in earlier versions,
> early_init_dt_reserve_memory_arch() takes no-map to mean memblock_remove().
> We trigger the removing via early_init_fdt_scan_reserved_mem() in
> arch/arm64/mm/init.c. This happens later than before, but its before the
> crashkernel and cma ranges get reserved.
>
> One difference I can see is that before we avoided memblock_remove()ing ranges
> that were also in memblock.nomap. This was to avoid the ACPI tables getting
> mapped as device memory by mistake, this is fixed by [1]. Now these ranges are
> published in /proc/iomem as 'reserved' and won't get covered by a
> reserved-memory node, and so we don't need to check memblock.nomap when
> memblock_remove()ing.
>
>
> The only odd thing I can see is for a (mythical?) pure-ACPI system. The EFI stub
> will create a DT with a chosen node containing pointers to the memory map and
> the efi command line. Now such as system may also grow a /reserved-memory node
> after kdump. I don't think this is a problem, but it may not match how an
> acpi-only system reserves memory. (how does that work?)
I didn't get what you mean by "may grow a /reserved-memory after kdump."
>
> > [1] "arm64: mark reserved memblock regions explicitly in iomem"
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/450433.html
>
> This is queued in Will's arm64/for-next/core,
>
> > [2] "efi: arm64: treat regions with WT/WC set but WB cleared as memory"
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/451491.html
>
> This is queued in tip, but I can't see why kdump depends on it. It only has an
> effect if the uefi memory map has !WB regions that linux needs to use.
Just because you said that the patch had fixed your problem on Seattle.
If I misunderstood, it will be fine to remove this reference from
my commit message.
Thanks,
-Takahiro AKASHI
>
> Thanks,
>
> James
>
^ permalink raw reply
* [PATCH 8/9] dmaengine: ti-dma-crossbar: Use enum for crossbar type
From: Peter Ujfalusi @ 2016-09-21 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921035226.GE2609@localhost>
On 09/21/16 06:52, Vinod Koul wrote:
> On Fri, Sep 16, 2016 at 11:33:23AM +0300, Peter Ujfalusi wrote:
>> Fixes compiler warning on 64bit architectures.
>
> Would be good to give the warning message here
Let me revert this patch and patch #2 for the eDMA to get the warnings.
I will repost v2 with the updated commit messages.
>
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>> drivers/dma/ti-dma-crossbar.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
>> index e4f3bd1ae264..876e4ccaf033 100644
>> --- a/drivers/dma/ti-dma-crossbar.c
>> +++ b/drivers/dma/ti-dma-crossbar.c
>> @@ -16,8 +16,10 @@
>> #include <linux/of_device.h>
>> #include <linux/of_dma.h>
>>
>> -#define TI_XBAR_DRA7 0
>> -#define TI_XBAR_AM335X 1
>> +enum ti_xbar_type {
>> + TI_XBAR_DRA7 = 0,
>> + TI_XBAR_AM335X,
>> +};
>>
>> static const struct of_device_id ti_dma_xbar_match[] = {
>> {
>> @@ -395,7 +397,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
>>
>> xbar->dmarouter.dev = &pdev->dev;
>> xbar->dmarouter.route_free = ti_dra7_xbar_free;
>> - xbar->dma_offset = (u32)match->data;
>> + xbar->dma_offset = (enum ti_xbar_type)match->data;
>>
>> mutex_init(&xbar->mutex);
>> platform_set_drvdata(pdev, xbar);
>> @@ -428,7 +430,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
>> if (unlikely(!match))
>> return -EINVAL;
>>
>> - switch ((u32)match->data) {
>> + switch ((enum ti_xbar_type)match->data) {
>> case TI_XBAR_DRA7:
>> ret = ti_dra7_xbar_probe(pdev);
>> break;
>> --
>> 2.10.0
>>
>
--
P?ter
^ permalink raw reply
* [PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735 charger
From: Jon Hunter @ 2016-09-21 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474394567.1215.14.camel@paulk.fr>
On 20/09/16 19:02, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 ? 18:40 +0100, Jon Hunter a ?crit :
>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>
>>> Nyan boards come with an embedded controller that controls when to
>>> enable and disable the charge. Thus, it should not be left up to the
>>> kernel to handle that.
>>>
>>> Using the ti,external-control property allows specifying this use-case.
>>
>> So the bq24735 is populated under the EC's 'i2c-tunnel' property which
>> is there to specifically interface it's child devices to the host. So I
>> am a bit confused why this is expose to the host if it should not be used?
>
> Well, it needs to access the information in the read-only registers provided by
> the chip, which is allowed by the setup in place that you described.
Is this to expose the current state to the kernel so we can monitor the
battery state?
> However, the EC has its internal state machine that decides when to start
> charging, etc and so should be the only one to write registers, to avoid
> conflicts.
>
>> Again you may right and I did find the original series [0] for this
>> which specifically references the Acer Chromebook that needs this.
>> However, I am not sure why this was never populated? Is there any other
>> history here?
>
> I am also confused about why it wasn't applied earlier. However, the cros kernel
> is using the very same scheme.
Do you have a reference?
>> What is the actual problem you see without making this change?
>
> There is a risk of conflict (even though it's probably not that significant),
> given the low variety of possible cases here. The idea is simply to say that the
> EC is in charge and to let it do its job without interfering.
>
>> The original series states ...
>>
>> "On Acer Chromebook 13 (CB5-311) this module fails to load if the
>> charger is not inserted, and will error when it is removed."
>
> I'm confused about that comment. At this point (and with this patch), it works
> normally.
Ok, I think Thierry prefers to only apply fixes for problems that can be
reproduced. Is there a simple way to check the battery status and
charging status via say the sysfs? If I can test that this has no
negative impact may be it is ok.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Hans de Goede @ 2016-09-21 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6718551474442396@web16h.yandex.ru>
Hi,
On 09/21/2016 10:19 AM, Icenowy Zheng wrote:
>
>
> 21.09.2016, 15:10, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 09/21/2016 10:04 AM, Icenowy Zheng wrote:
>>> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>>> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>>> (which is a Host-only controller, but more stable and easy to implement).
>>>
>>> This property marks whether on a certain board which controller should be
>>> attached to the PHY.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>
>> Erm, I think that the idea here is to dynamically switch the routing
>> based on the id-pin of the otg connector. IOW use the musb controller
>> for device mode, and the ehci/ohci proper for proper host support
>> when in host mode.
>
> At least on some boards this implementation works...
>
> (I mean Pine64, which has two USB-A connectors)
Right and I think it is great that you're working on this.
But even with an A connector on the board, we can still use the device
mode (e.g. the SoC's native FEL mode will be used this way).
Notice that you can fake id-pin changes by echoing a mode to:
/sys/devices/platform/soc at 01c00000/1c13000.usb/musb-hdrc.1.auto/mode
Valid values to echo are: host, peripheral and otg.
If you combine this with using either an USB A<->A cable, or using
the port normally as a host you should be able to develop and test
full otg support.
Eventually we will need a full otg support rather then your current solution
and I'm afraid that your solution may get in the way of full otg support.
Regards,
Hans
^ permalink raw reply
* [PATCH] gpio: Added zynq specific check for special pins on bank zero
From: Michal Simek @ 2016-09-21 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920140633.GD16583@xsjsorenbubuntu>
On 20.9.2016 16:06, S?ren Brinkmann wrote:
> On Tue, 2016-09-20 at 14:02:04 +0530, Nava kishore Manne wrote:
>> From: Nava kishore Manne <nava.manne@xilinx.com>
>>
>> This patch adds zynq specific check for bank 0 pins 7 and 8
>> are special and cannot be used as inputs
>>
>> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
>> ---
>> drivers/gpio/gpio-zynq.c | 17 +++++++++++++++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
>> index e72794e..eae9d24 100644
>> --- a/drivers/gpio/gpio-zynq.c
>> +++ b/drivers/gpio/gpio-zynq.c
>> @@ -96,6 +96,10 @@
>> /* GPIO upper 16 bit mask */
>> #define ZYNQ_GPIO_UPPER_MASK 0xFFFF0000
>>
>> +/* For GPIO quirks */
>> +#define ZYNQ_GPIO BIT(0)
>> +#define ZYNQMP_GPIO BIT(1)
>
> I'd make sure all quirks are easily identifiable and call them something
> like 'ZYNQ_GPIO_QUIRK_FOO'
>
> Apart from that:
> Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
>
This issue was:
Reported-by: Jonas Karlsson <Jonas.d.karlsson@gmail.com>
And here is also my:
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/7059a368/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] dt: bindings: add allwinner, otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-09-21 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a1ab62a-4091-fd75-d753-fb30585dffa5@redhat.com>
21.09.2016, 15:10, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 09/21/2016 10:04 AM, Icenowy Zheng wrote:
>> ?On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>> ?the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>> ?(which is a Host-only controller, but more stable and easy to implement).
>>
>> ?This property marks whether on a certain board which controller should be
>> ?attached to the PHY.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Erm, I think that the idea here is to dynamically switch the routing
> based on the id-pin of the otg connector. IOW use the musb controller
> for device mode, and the ehci/ohci proper for proper host support
> when in host mode.
At least on some boards this implementation works...
(I mean Pine64, which has two USB-A connectors)
>
> Regards,
>
> Hans
>
>> ?---
>> ??Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 7 +++++++
>> ??1 file changed, 7 insertions(+)
>>
>> ?diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?index 287150d..5c11d57 100644
>> ?--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?@@ -36,6 +36,13 @@ Optional properties:
>> ??- usb1_vbus-supply : regulator phandle for controller usb1 vbus
>> ??- usb2_vbus-supply : regulator phandle for controller usb2 vbus
>>
>> ?+Optional properties for H3 or A64 SoCs:
>> ?+- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
>> ?+ MUSB. (boolean, if this property is set, the OHCI/EHCI
>> ?+ controllers at PHY0 should be enabled and the MUSB
>> ?+ controller must *NOT* be enabled, and thus the PHY can
>> ?+ only work in host mode)
>> ?+
>> ??Example:
>> ??????????usbphy: phy at 0x01c13400 {
>> ??????????????????#phy-cells = <1>;
^ permalink raw reply
* [PATCH v2] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-21 7:19 UTC (permalink / raw)
To: linux-arm-kernel
Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
by using aarch64_insn_write() instead of probe_kernel_write().
See how this works:
commit 2f896d586610 ("arm64: use fixmap for text patching")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: <stable@vger.kernel.org> # 3.18-3.19: 2f896d5: arm64: use fixmap
Cc: <stable@vger.kernel.org> # 4.0-
---
arch/arm64/include/asm/debug-monitors.h | 2 --
arch/arm64/kernel/kgdb.c | 36 ++++++++++++++++++++++-----------
2 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 4b6b3f7..b71420a 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -61,8 +61,6 @@
#define AARCH64_BREAK_KGDB_DYN_DBG \
(AARCH64_BREAK_MON | (KGDB_DYN_DBG_BRK_IMM << 5))
-#define KGDB_DYN_BRK_INS_BYTE(x) \
- ((AARCH64_BREAK_KGDB_DYN_DBG >> (8 * (x))) & 0xff)
#define CACHE_FLUSH_IS_SAFE 1
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index 6732a27..b06a7a2 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -19,6 +19,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/bug.h>
#include <linux/cpumask.h>
#include <linux/irq.h>
#include <linux/irq_work.h>
@@ -26,6 +27,8 @@
#include <linux/kgdb.h>
#include <linux/kprobes.h>
#include <linux/percpu.h>
+#include <asm/debug-monitors.h>
+#include <asm/insn.h>
#include <asm/ptrace.h>
#include <asm/traps.h>
@@ -370,15 +373,24 @@ void kgdb_arch_exit(void)
unregister_die_notifier(&kgdb_notifier);
}
-/*
- * ARM instructions are always in LE.
- * Break instruction is encoded in LE format
- */
-struct kgdb_arch arch_kgdb_ops = {
- .gdb_bpt_instr = {
- KGDB_DYN_BRK_INS_BYTE(0),
- KGDB_DYN_BRK_INS_BYTE(1),
- KGDB_DYN_BRK_INS_BYTE(2),
- KGDB_DYN_BRK_INS_BYTE(3),
- }
-};
+struct kgdb_arch arch_kgdb_ops;
+
+int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
+{
+ int err;
+
+ BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
+
+ err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
+ if (err)
+ return err;
+
+ return aarch64_insn_write((void *)bpt->bpt_addr,
+ (u32)AARCH64_BREAK_KGDB_DYN_DBG);
+}
+
+int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
+{
+ return aarch64_insn_write((void *)bpt->bpt_addr,
+ *(u32 *)bpt->saved_instr);
+}
--
2.10.0
^ permalink raw reply related
* [PATCH] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-21 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920103333.GB1045@leverpostej>
On Tue, Sep 20, 2016 at 11:33:34AM +0100, Mark Rutland wrote:
> On Tue, Sep 20, 2016 at 07:03:21PM +0900, AKASHI Takahiro wrote:
> > Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
> > by using aarch64_insn_write() instead of probe_kernel_write().
> > See how this works:
> > commit 2f896d586610 ("arm64: use fixmap for text patching")
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Jason Wessel <jason.wessel@windriver.com>
> > Cc: <stable@vger.kernel.org> # 4.0-
>
> We had SET_MODULE_RONX in v3.17, and we had KGDB before that, so we need
> something for v3.17+.
Right, but 3.18+ :)
Unfortunately, the patch ("arm64: use fixmap for text patching")
is merged only in v4.0 or later. So it is also a pre-requisite.
> > ---
> > arch/arm64/kernel/kgdb.c | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> > index 6732a27..133cfe3 100644
> > --- a/arch/arm64/kernel/kgdb.c
> > +++ b/arch/arm64/kernel/kgdb.c
> > @@ -382,3 +382,23 @@ struct kgdb_arch arch_kgdb_ops = {
> > KGDB_DYN_BRK_INS_BYTE(3),
> > }
> > };
> > +int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> > +{
> > + int err;
> > +
> > + BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
> > +
> > + err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
> > + if (err)
> > + return err;
> > +
> > + return aarch64_insn_write((void *)bpt->bpt_addr,
> > + (u32)AARCH64_BREAK_KGDB_DYN_DBG);
> > +}
>
> This changes the endianness of saved_instr (on BE), but it looks like
> that's handed as an opaque token by the core code anyway, so that should
> be fine.
>
> This also renders arch_kgdb_ops.gdb_bpt_instr unused. Can/should we get
> rid of that?
Yes, we can. But arch_kgdb_ops is still needed for compiling anyway.
> > +int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> > +{
> > + return aarch64_insn_write((void *)bpt->bpt_addr,
> > + *(u32 *)bpt->saved_instr);
> > +}
>
> We also need a few additional includes:
>
> <asm/debug-monitors.h> # for BREAK_INSTR_SIZE, AARCH64_BREAK_KGDB_DYN_DBG
> <asm/insn.h> # for AARCH64_INSN_SIZE, insn_{read,write}
> <linux/bug.h> # for BUILD_BUG_ON()
Added.
> I take it that we're protected against nesting within
> aarch64_insn_write(), so that we can't deadlock on patch_lock?
>
> Other than that, this looks good to me.
Thanks,
-Takahiro AKASHI
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Hans de Goede @ 2016-09-21 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921070406.27445-1-icenowy@aosc.xyz>
Hi,
On 09/21/2016 10:04 AM, Icenowy Zheng wrote:
> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
> (which is a Host-only controller, but more stable and easy to implement).
>
> This property marks whether on a certain board which controller should be
> attached to the PHY.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Erm, I think that the idea here is to dynamically switch the routing
based on the id-pin of the otg connector. IOW use the musb controller
for device mode, and the ehci/ohci proper for proper host support
when in host mode.
Regards,
Hans
> ---
> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 287150d..5c11d57 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -36,6 +36,13 @@ Optional properties:
> - usb1_vbus-supply : regulator phandle for controller usb1 vbus
> - usb2_vbus-supply : regulator phandle for controller usb2 vbus
>
> +Optional properties for H3 or A64 SoCs:
> +- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
> + MUSB. (boolean, if this property is set, the OHCI/EHCI
> + controllers at PHY0 should be enabled and the MUSB
> + controller must *NOT* be enabled, and thus the PHY can
> + only work in host mode)
> +
> Example:
> usbphy: phy at 0x01c13400 {
> #phy-cells = <1>;
>
^ permalink raw reply
* [PATCH 2/2] phy-sun4i-usb: add support for host mode of phy0 on A64 SoC
From: Icenowy Zheng @ 2016-09-21 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921070406.27445-1-icenowy@aosc.xyz>
The OTG phy of A64 can be put into the host mode with an OHCI/EHCI pair,
just like the H3 SoC.
Some A64 boards (such as Pine64 series) use the USB OTG port as a generic
USB-A port, and thus can be fully support by the driver now.
The register's name is changed to PHY_OTG_CFG, as it's described in the
A64 downstream BSP kernel source, at drivers/usb/host/sunxi_hci.h .
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
drivers/phy/phy-sun4i-usb.c | 46 +++++++++++++++++++++++++++++++++------------
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index a4db658..9287247 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -47,7 +47,7 @@
#define REG_PHYBIST 0x08
#define REG_PHYTUNE 0x0c
#define REG_PHYCTL_A33 0x10
-#define REG_PHY_UNK_H3 0x20
+#define REG_PHY_OTG_CFG 0x20
#define REG_PMU_UNK1 0x10
@@ -107,6 +107,7 @@ struct sun4i_usb_phy_cfg {
u8 phyctl_offset;
bool dedicated_clocks;
bool enable_pmu_unk1;
+ bool route_otg;
};
struct sun4i_usb_phy_data {
@@ -135,6 +136,7 @@ struct sun4i_usb_phy_data {
int id_det;
int vbus_det;
struct delayed_work detect;
+ bool otg_routed;
};
#define to_sun4i_usb_phy_data(phy) \
@@ -263,10 +265,11 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val & ~2, phy->pmu + REG_PMU_UNK1);
}
- if (data->cfg->type == sun8i_h3_phy) {
- if (phy->index == 0) {
- val = readl(data->base + REG_PHY_UNK_H3);
- writel(val & ~1, data->base + REG_PHY_UNK_H3);
+ if (data->cfg->route_otg) {
+ if (phy->index == 0 && data->otg_routed) {
+ /* Route the OTG PHY to HCI */
+ val = readl(data->base + REG_PHY_OTG_CFG);
+ writel(val & ~1, data->base + REG_PHY_OTG_CFG);
}
} else {
/* Enable USB 45 Ohm resistor calibration */
@@ -283,7 +286,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
sun4i_usb_phy_passby(phy, 1);
- if (phy->index == 0) {
+ if (phy->index == 0 && !data->otg_routed) {
data->phy0_init = true;
/* Enable pull-ups */
@@ -310,7 +313,7 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
- if (phy->index == 0) {
+ if (phy->index == 0 && !data->otg_routed) {
/* Disable pull-ups */
sun4i_usb_phy0_update_iscr(_phy, ISCR_DPDM_PULLUP_EN, 0);
sun4i_usb_phy0_update_iscr(_phy, ISCR_ID_PULLUP_EN, 0);
@@ -377,7 +380,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
/* For phy0 only turn on Vbus if we don't have an ext. Vbus */
if (phy->index == 0 && sun4i_usb_phy0_have_vbus_det(data) &&
- data->vbus_det)
+ data->vbus_det && !data->otg_routed)
return 0;
ret = regulator_enable(phy->vbus);
@@ -387,7 +390,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
phy->regulator_on = true;
/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
- if (phy->index == 0 && sun4i_usb_phy0_poll(data))
+ if (phy->index == 0 && sun4i_usb_phy0_poll(data) && !data->otg_routed)
mod_delayed_work(system_wq, &data->detect, DEBOUNCE_TIME);
return 0;
@@ -408,7 +411,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
* phy0 vbus typically slowly discharges, sometimes this causes the
* Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
*/
- if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
+ if (phy->index == 0 && !sun4i_usb_phy0_poll(data) && !data->otg_routed)
mod_delayed_work(system_wq, &data->detect, POLL_TIME);
return 0;
@@ -567,7 +570,17 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
return -ENOMEM;
mutex_init(&data->mutex);
- INIT_DELAYED_WORK(&data->detect, sun4i_usb_phy0_id_vbus_det_scan);
+ if (device_property_read_bool(dev, "allwinner,otg-routed")) {
+ /*
+ * PHY0 is routed to HCI rather than OTG Controller.
+ * In this situation, the port can only be used as a host port.
+ */
+ data->otg_routed = true;
+ } else {
+ /* ID/Vbus detection is only meaningful when it's really OTG */
+ INIT_DELAYED_WORK(&data->detect,
+ sun4i_usb_phy0_id_vbus_det_scan);
+ }
dev_set_drvdata(dev, data);
data->cfg = of_device_get_match_data(dev);
if (!data->cfg)
@@ -647,7 +660,8 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
return PTR_ERR(phy->reset);
}
- if (i) { /* No pmu for usbc0 */
+ /* PMU is only valid on PHYs in HCI mode */
+ if (i || data->otg_routed) {
snprintf(name, sizeof(name), "pmu%d", i);
res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
@@ -719,6 +733,7 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
@@ -728,6 +743,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
@@ -737,6 +753,7 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
@@ -746,6 +763,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
@@ -755,6 +773,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
@@ -764,6 +783,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
@@ -772,6 +792,7 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.disc_thresh = 3,
.dedicated_clocks = true,
.enable_pmu_unk1 = true,
+ .route_otg = true,
};
static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
@@ -781,6 +802,7 @@ static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
.enable_pmu_unk1 = true,
+ .route_otg = true,
};
static const struct of_device_id sun4i_usb_phy_of_match[] = {
--
2.10.0
^ permalink raw reply related
* [PATCH 1/2] dt: bindings: add allwinner, otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-09-21 7:04 UTC (permalink / raw)
To: linux-arm-kernel
On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
(which is a Host-only controller, but more stable and easy to implement).
This property marks whether on a certain board which controller should be
attached to the PHY.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 287150d..5c11d57 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -36,6 +36,13 @@ Optional properties:
- usb1_vbus-supply : regulator phandle for controller usb1 vbus
- usb2_vbus-supply : regulator phandle for controller usb2 vbus
+Optional properties for H3 or A64 SoCs:
+- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
+ MUSB. (boolean, if this property is set, the OHCI/EHCI
+ controllers at PHY0 should be enabled and the MUSB
+ controller must *NOT* be enabled, and thus the PHY can
+ only work in host mode)
+
Example:
usbphy: phy at 0x01c13400 {
#phy-cells = <1>;
--
2.10.0
^ permalink raw reply related
* [v12, 8/8] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu@nxp.com>
The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version.
Acturally the right version numbers should be VVN=0x13 and SVN = 0x1.
This patch adds the GUTS driver support for eSDHC driver to match SoC.
And fix host version to avoid that incorrect version numbers break down
the ADMA data transfer.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Scott Wood <oss@buserror.net>
---
Changes for v2:
- Got SVR through iomap instead of dts
Changes for v3:
- Managed GUTS through syscon instead of iomap in eSDHC driver
Changes for v4:
- Got SVR by GUTS driver instead of SYSCON
Changes for v5:
- Changed to get SVR through API fsl_guts_get_svr()
- Combined patch 4, patch 5 and patch 6 into one
Changes for v6:
- Added 'Acked-by: Ulf Hansson'
Changes for v7:
- None
Changes for v8:
- Added 'Acked-by: Scott Wood'
Changes for v9:
- None
Changes for v10:
- None
Changes for v11:
- Changed to use soc_device_match
Changes for v12:
- Matched soc through .family field instead of .soc_id
---
drivers/mmc/host/Kconfig | 1 +
drivers/mmc/host/sdhci-of-esdhc.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 5274f50..a1135a9 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -144,6 +144,7 @@ config MMC_SDHCI_OF_ESDHC
depends on MMC_SDHCI_PLTFM
depends on PPC || ARCH_MXC || ARCH_LAYERSCAPE
select MMC_SDHCI_IO_ACCESSORS
+ select FSL_GUTS
help
This selects the Freescale eSDHC controller support.
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index fb71c86..57bdb9e 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,6 +18,7 @@
#include <linux/of.h>
#include <linux/delay.h>
#include <linux/module.h>
+#include <linux/sys_soc.h>
#include <linux/mmc/host.h>
#include "sdhci-pltfm.h"
#include "sdhci-esdhc.h"
@@ -28,6 +29,7 @@
struct sdhci_esdhc {
u8 vendor_ver;
u8 spec_ver;
+ bool quirk_incorrect_hostver;
};
/**
@@ -73,6 +75,8 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
static u16 esdhc_readw_fixup(struct sdhci_host *host,
int spec_reg, u32 value)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
u16 ret;
int shift = (spec_reg & 0x2) * 8;
@@ -80,6 +84,12 @@ static u16 esdhc_readw_fixup(struct sdhci_host *host,
ret = value & 0xffff;
else
ret = (value >> shift) & 0xffff;
+ /* Workaround for T4240-R1.0-R2.0 eSDHC which has incorrect
+ * vendor version and spec version information.
+ */
+ if ((spec_reg == SDHCI_HOST_VERSION) &&
+ (esdhc->quirk_incorrect_hostver))
+ ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
return ret;
}
@@ -558,6 +568,12 @@ static const struct sdhci_pltfm_data sdhci_esdhc_le_pdata = {
.ops = &sdhci_esdhc_le_ops,
};
+static struct soc_device_attribute soc_incorrect_hostver[] = {
+ { .family = "QorIQ T4240", .revision = "1.0", },
+ { .family = "QorIQ T4240", .revision = "2.0", },
+ { },
+};
+
static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
{
struct sdhci_pltfm_host *pltfm_host;
@@ -571,6 +587,10 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
+ if (soc_device_match(soc_incorrect_hostver))
+ esdhc->quirk_incorrect_hostver = true;
+ else
+ esdhc->quirk_incorrect_hostver = false;
}
static int sdhci_esdhc_probe(struct platform_device *pdev)
--
2.1.0.27.g96db324
^ permalink raw reply related
* [v12, 7/8] base: soc: introduce soc_device_match() interface
From: Yangbo Lu @ 2016-09-21 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu@nxp.com>
From: Arnd Bergmann <arnd@arndb.de>
We keep running into cases where device drivers want to know the exact
version of the a SoC they are currently running on. In the past, this has
usually been done through a vendor specific API that can be called by a
driver, or by directly accessing some kind of version register that is
not part of the device itself but that belongs to a global register area
of the chip.
Common reasons for doing this include:
- A machine is not using devicetree or similar for passing data about
on-chip devices, but just announces their presence using boot-time
platform devices, and the machine code itself does not care about the
revision.
- There is existing firmware or boot loaders with existing DT binaries
with generic compatible strings that do not identify the particular
revision of each device, but the driver knows which SoC revisions
include which part.
- A prerelease version of a chip has some quirks and we are using the same
version of the bootloader and the DT blob on both the prerelease and the
final version. An update of the DT binding seems inappropriate because
that would involve maintaining multiple copies of the dts and/or
bootloader.
This patch introduces the soc_device_match() interface that is meant to
work like of_match_node() but instead of identifying the version of a
device, it identifies the SoC itself using a vendor-agnostic interface.
Unlike of_match_node(), we do not do an exact string compare but instead
use glob_match() to allow wildcards in strings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v11:
- Added this patch for soc match
Changes for v12:
- Corrected the author
- Rewrited soc_device_match with while loop
---
drivers/base/Kconfig | 1 +
drivers/base/soc.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/sys_soc.h | 3 +++
3 files changed, 70 insertions(+)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 98504ec..f1591ad2 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
source "drivers/base/regmap/Kconfig"
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 75b98aa..d2fd1ad 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -14,6 +14,7 @@
#include <linux/spinlock.h>
#include <linux/sys_soc.h>
#include <linux/err.h>
+#include <linux/glob.h>
static DEFINE_IDA(soc_ida);
@@ -168,3 +169,68 @@ static void __exit soc_bus_unregister(void)
bus_unregister(&soc_bus_type);
}
module_exit(soc_bus_unregister);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+ struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+ const struct soc_device_attribute *match = arg;
+
+ if (match->machine &&
+ !glob_match(match->machine, soc_dev->attr->machine))
+ return 0;
+
+ if (match->family &&
+ !glob_match(match->family, soc_dev->attr->family))
+ return 0;
+
+ if (match->revision &&
+ !glob_match(match->revision, soc_dev->attr->revision))
+ return 0;
+
+ if (match->soc_id &&
+ !glob_match(match->soc_id, soc_dev->attr->soc_id))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches)
+{
+ int ret = 0;
+
+ if (!matches)
+ return NULL;
+
+ while (!ret) {
+ if (!(matches->machine || matches->family ||
+ matches->revision || matches->soc_id))
+ break;
+ ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
+ soc_device_match_one);
+ if (!ret)
+ matches++;
+ else
+ return matches;
+ }
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb..9f5eb06 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,7 @@ struct soc_device_attribute {
const char *family;
const char *revision;
const char *soc_id;
+ const void *data;
};
/**
@@ -34,4 +35,6 @@ void soc_device_unregister(struct soc_device *soc_dev);
*/
struct device *soc_device_to_device(struct soc_device *soc);
+const struct soc_device_attribute *soc_device_match(
+ const struct soc_device_attribute *matches);
#endif /* __SOC_BUS_H */
--
2.1.0.27.g96db324
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox