* PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
From: Michael Niewöhner @ 2016-10-18 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4d744ae-d043-b652-3073-f29ebe76f865@codeaurora.org>
Hi,
On Mon, 2016-10-17 at 15:21 +0530, Vivek Gautam wrote:
>
> On 10/17/2016 01:38 PM, Felipe Balbi wrote:
> > Hi,
> >
> > Michael Niew?hner <linux@mniewoehner.de> writes:
> > > Hi Felipe,
> > > On Fri, 2016-10-07 at 22:26 +0200, Michael Niew?hner wrote:
> > > > Hi Felipe,
> > > >
> > > > On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:
> > > > > Hi,
> > > > >
> > > > > Michael Niew?hner <linux@mniewoehner.de> writes:
> > > > > > > The clocks are same across working/non-working.
> > > > > > > Is it possible to bisect the commit that's causing hang for 4.8x ?
> > > > > >
> > > > > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and exit paths
> > > > > > This patch causes both the hang on reboot and the lsusb hang.
> > > > >
> > > > > How to reproduce? Why don't we see this on x86 and TI boards? I'm
> > > > > guessing this is failed bisection, as I can't see anything in that
> > > > > commit that would cause reboot hang. Also, that code path is *NOT*
> > > > > executed when you run lsusb.
> > > > >
> > > >
> > > > I've tested this procedure multiple times to be sure:
> > > >
> > > > - checkout c499ff71, compile, boot the odroid
> > > > - run lsusb -v => lsusb hangs, can't terminate with ctrl-c
> > > > - hard reset, after boot run poweroff or reboot => board does not completely power off / reboot (see log below)
> > > > - revert c499ff71, mrproper, compile, boot the odroid
> > > > - run lsusb -v => shows full output, not hanging
> > > > - run reboot or poweroff => board powers off / reboots just fine
> > > >
> > > >
> > > > dmesg poweroff not working:
> > > > ...
> > > > [??120.733519] systemd-journald[144]: systemd-journald stopped as pid 144
> > > > [??120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
> > > > [??120.769212] systemd-shutdown[1]: Unmounting file systems.
> > > > [??120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
> > > > [??120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.
> > > > [??121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.101014] systemd-shutdown[1]: All filesystems unmounted.
> > > > [??121.106523] systemd-shutdown[1]: Deactivating swaps.
> > > > [??121.111585] systemd-shutdown[1]: All swaps deactivated.
> > > > [??121.116661] systemd-shutdown[1]: Detaching loop devices.
> > > > [??121.126395] systemd-shutdown[1]: All loop devices detached.
> > > > [??121.130525] systemd-shutdown[1]: Detaching DM devices.
> > > > [??121.135824] systemd-shutdown[1]: All DM devices detached.
> > > > [??121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.
> > > > [??121.171739] systemd-shutdown[1]: Powering off.
> > > >
> > > > => at this point removing the sd card would show a message
> > > > "removed mmc0" (not sure what the real message was...) so the board is not completely off.
> > > >
> > > >
> > > > dmesg poweroff working:
> > > > ...
> > > > [??120.733519] systemd-journald[144]: systemd-journald stopped as pid 144
> > > > [??120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
> > > > [??120.769212] systemd-shutdown[1]: Unmounting file systems.
> > > > [??120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
> > > > [??120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.
> > > > [??121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> > > > [??121.101014] systemd-shutdown[1]: All filesystems unmounted.
> > > > [??121.106523] systemd-shutdown[1]: Deactivating swaps.
> > > > [??121.111585] systemd-shutdown[1]: All swaps deactivated.
> > > > [??121.116661] systemd-shutdown[1]: Detaching loop devices.
> > > > [??121.126395] systemd-shutdown[1]: All loop devices detached.
> > > > [??121.130525] systemd-shutdown[1]: Detaching DM devices.
> > > > [??121.135824] systemd-shutdown[1]: All DM devices detached.
> > > > [??121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.
> > > > [??121.171739] systemd-shutdown[1]: Powering off.
> > > > [??121.182331] rebo?
> > > >
> > > >
> > > >
> > > > Best regards
> > > > Michael Niew?hner
> > >
> > > I did some more tests with next-20161016. Reverting / commenting out
> > > one part of your patch "solves" the lsusb hang, the reboot problem
> > > and also the "debounce failed" message. [1]
> > > Another "solution" is to call phy_power_off before phy_power_on. [2]
> > >
> > > Disclaimer: I have no idea what I was doing ;-) These were just some
> > > simple trial-and-error attempts that maybe help to find the real
> > > cause of the problems.
> > >
> > > [1]
> > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > index 7287a76..5ef589d 100644
> > > --- a/drivers/usb/dwc3/core.c
> > > +++ b/drivers/usb/dwc3/core.c
> > > @@ -724,6 +724,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
> > > ?? /* Adjust Frame Length */
> > > ?? dwc3_frame_length_adjustment(dwc);
> > > ??
> > > +/*
> > > ?? usb_phy_set_suspend(dwc->usb2_phy, 0);
> > > ?? usb_phy_set_suspend(dwc->usb3_phy, 0);
> > > ?? ret = phy_power_on(dwc->usb2_generic_phy);
> > > @@ -733,6 +734,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
> > > ?? ret = phy_power_on(dwc->usb3_generic_phy);
> > > ?? if (ret < 0)
> > > ?? goto err3;
> > > +*/
> > > ??
> > > ?? ret = dwc3_event_buffers_setup(dwc);
> > > ?? if (ret) {
> > >
> > > [2]
> > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > index 7287a76..f6c8e13 100644
> > > --- a/drivers/usb/dwc3/core.c
> > > +++ b/drivers/usb/dwc3/core.c
> > > @@ -726,6 +726,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
> > > ??
> > > ?????????usb_phy_set_suspend(dwc->usb2_phy, 0);
> > > ?????????usb_phy_set_suspend(dwc->usb3_phy, 0);
> > > +???????phy_power_off(dwc->usb2_generic_phy);
> > > +???????phy_power_off(dwc->usb3_generic_phy);
> >
> > This looks like a PHY driver bug to me. Which PHY driver are you using?
> >
>
> The exynos5-usbdrd phy driver is used for exynos platforms.
> Looks like something is not right with the phy driver even
> after applying the phy_calibrate patches.
>
> Michael, are you using the last set of patches for phy calibration [1]?
> [1] https://lkml.org/lkml/2015/2/2/257.
yes, I'm using the original LOS level patch.
The phy patch doesn't apply to next, so I use this adapted patch:
https://github.com/c0d3z3r0/linux/commit/8b7a0b2a19e235c308b9082a14ffe73477e2c9ed
>
>
> Thanks
> Vivek
>
Michael
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-18 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018114932.GG10115@e104818-lin.cambridge.arm.com>
On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
>> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
>> currently work, or have ever worked correctly when built for big endian. So this
>> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
>> well, and an additional fix for XTS which escaped my attention before.
>>
>> Each of these patches carries a fixes tag, and could be backported to stable.
>> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
>> fix is compatible with, not the patch that introduced the algorithm.
>
> I think for future reference, the Fixes tag should denote the commit
> that introduced the issue. An explicit Cc: stable tag would state how
> far back it should be applied.
>
OK, that sounds reasonable.
>> Ard Biesheuvel (8):
>> crypto: arm64/aes-ce - fix for big endian
>> crypto: arm64/ghash-ce - fix for big endian
>> crypto: arm64/sha1-ce - fix for big endian
>> crypto: arm64/sha2-ce - fix for big endian
>> crypto: arm64/aes-ccm-ce: fix for big endian
>> crypto: arm64/aes-neon - fix for big endian
>> crypto: arm64/aes-xts-ce: fix for big endian
>> crypto: arm/aes-ce - fix for big endian
>
> The changes look fine to me but I can't claim I fully understand these
> algorithms. FWIW:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> (Will may pick them up for 4.9-rcX)
Thanks, although I was kind of expecting Herbert to pick these up,
given that #8 affects ARM not arm64.
But if you (or Will) can pick up #1 to #7, that is also fine, then I
can drop #8 into rmk's patch database.
Thanks,
Ard,
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ziji Hu @ 2016-10-18 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ec7a2658-5af3-bff8-3cb8-adb72406df5c@intel.com>
Hi Adrian,
On 2016/10/17 16:14, Adrian Hunter wrote:
> On 13/10/16 08:38, Ziji Hu wrote:
>> Hi Adrian,
>>
>> On 2016/10/12 21:07, Adrian Hunter wrote:
>>> On 12/10/16 14:58, Ziji Hu wrote:
>>>> Hi Adrian,
>>>>
>>>> Thank you very much for your review.
>>>> I will firstly fix the typo.
>>>>
>>>> On 2016/10/11 20:37, Adrian Hunter wrote:
>> <snip>
>>>>>> +
>>>>>> +static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>>>>> + struct mmc_ios *ios)
>>>>>> +{
>>>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>>> +
>>>>>> + /*
>>>>>> + * Before SD/SDIO set signal voltage, SD bus clock should be
>>>>>> + * disabled. However, sdhci_set_clock will also disable the Internal
>>>>>> + * clock in mmc_set_signal_voltage().
>>>>>> + * If Internal clock is disabled, the 3.3V/1.8V bit can not be updated.
>>>>>> + * Thus here manually enable internal clock.
>>>>>> + *
>>>>>> + * After switch completes, it is unnecessary to disable internal clock,
>>>>>> + * since keeping internal clock active obeys SD spec.
>>>>>> + */
>>>>>> + enable_xenon_internal_clk(host);
>>>>>> +
>>>>>> + if (priv->card_candidate) {
>>>>>
>>>>> mmc_power_up() calls __mmc_set_signal_voltage() calls
>>>>> host->ops->start_signal_voltage_switch so priv->card_candidate could be an
>>>>> invalid reference to an old card.
>>>>>
>>>>> So that's not going to work if the card changes - not only for removable
>>>>> cards but even for eMMC if init fails and retries.
>>>>>
>>>> As you point out, this piece of code have defects, even though it actually works on Marvell multiple platforms, unless eMMC card is removable.
>>>>
>>>> I can add a property to explicitly indicate eMMC type in DTS.
>>>> Then card_candidate access can be removed here.
>>>> Does it sounds more reasonable to you?
>>>
>>> Sure
>>>
>>>>
>>>>>> + if (mmc_card_mmc(priv->card_candidate))
>>>>>> + return xenon_emmc_signal_voltage_switch(mmc, ios);
>>>>>
>>>>> So if all you need to know is whether it is a eMMC, why can't DT tell you?
>>>>>
>>>> I can add an eMMC type property in DTS, to remove the card_candidate access here.
>>>>
>>>>>> + }
>>>>>> +
>>>>>> + return sdhci_start_signal_voltage_switch(mmc, ios);
>>>>>> +}
>>>>>> +
>>>>>> +/*
>>>>>> + * After determining which slot is used for SDIO,
>>>>>> + * some additional task is required.
>>>>>> + */
>>>>>> +static void xenon_init_card(struct mmc_host *mmc, struct mmc_card *card)
>>>>>> +{
>>>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>>>> + u32 reg;
>>>>>> + u8 slot_idx;
>>>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>>> +
>>>>>> + /* Link the card for delay adjustment */
>>>>>> + priv->card_candidate = card;
>>>>>
>>>>> You really need a better way to get the card. I suggest you take up the
>>>>> issue with Ulf. One possibility is to have mmc core set host->card = card
>>>>> much earlier.
>>>>>
>>>> Could you please tell me if any issue related to card_candidate still exists, after the card_candidate is removed from xenon_start_signal_voltage_switch() in above?
>>>> It seems that when init_card is called, the structure card has already been updated and stable in MMC/SD/SDIO initialization sequence.
>>>> May I keep it here?
>>>
>>> It works by accident rather than by design. We can do better.
>>>
>> Could you please tell me some details which are satisfied about card_candidate?
>>
>> I must admit that card_candidate in xenon_start_signal_voltage_switch() is imperfect.
>> But card_candidate in init_card() and later in set_ios() work by design, rather than by accident. We did a lot of tests on several platforms.
>>
>> The structure mmc_card passed in here is a stable one. Thus in my very own opinion, it is safe and stable to use mmc_card here.
>> card_candidate is used only in card initialization. It is not active in later transfers after initialization is done.
>> It will always updated with mmc_card in next card initialization.
>
> Ok, so maybe just add some comments and more explanation of how it works.
>
>
Sure. I will add more detailed comments.
>>
>>>>
>>>>>> + /* Set tuning functionality of this slot */
>>>>>> + xenon_slot_tuning_setup(host);
>>>>>> +
>>>>>> + slot_idx = priv->slot_idx;
>>>>>> + if (!mmc_card_sdio(card)) {
>>>>>> + /* Re-enable the Auto-CMD12 cap flag. */
>>>>>> + host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
>>>>>> + host->flags |= SDHCI_AUTO_CMD12;
>>>>>> +
>>>>>> + /* Clear SDIO Card Inserted indication */
>>>>>> + reg = sdhci_readl(host, SDHC_SYS_CFG_INFO);
>>>>>> + reg &= ~(1 << (slot_idx + SLOT_TYPE_SDIO_SHIFT));
>>>>>> + sdhci_writel(host, reg, SDHC_SYS_CFG_INFO);
>>>>>> +
>>>>>> + if (mmc_card_mmc(card)) {
>>>>>> + mmc->caps |= MMC_CAP_NONREMOVABLE;
>>>>>> + if (!(host->quirks2 & SDHCI_QUIRK2_NO_1_8_V))
>>>>>> + mmc->caps |= MMC_CAP_1_8V_DDR;
>>>>>> + /*
>>>>>> + * Force to clear BUS_TEST to
>>>>>> + * skip bus_test_pre and bus_test_post
>>>>>> + */
>>>>>> + mmc->caps &= ~MMC_CAP_BUS_WIDTH_TEST;
>>>>>> + mmc->caps2 |= MMC_CAP2_HC_ERASE_SZ |
>>>>>> + MMC_CAP2_PACKED_CMD;
>>>>>> + if (mmc->caps & MMC_CAP_8_BIT_DATA)
>>>>>> + mmc->caps2 |= MMC_CAP2_HS400_1_8V;
>>>>>> + }
>>>>>> + } else {
>>>>>> + /*
>>>>>> + * Delete the Auto-CMD12 cap flag.
>>>>>> + * Otherwise, when sending multi-block CMD53,
>>>>>> + * Driver will set Transfer Mode Register to enable Auto CMD12.
>>>>>> + * However, SDIO device cannot recognize CMD12.
>>>>>> + * Thus SDHC will time-out for waiting for CMD12 response.
>>>>>> + */
>>>>>> + host->quirks &= ~SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
>>>>>> + host->flags &= ~SDHCI_AUTO_CMD12;
>>>>>
>>>>> sdhci_set_transfer_mode() won't enable auto-CMD12 for CMD53 anyway, so is
>>>>> this needed?
>>>>>
>>>> In Xenon driver, Auto-CMD12 flag is set to enable full support to Auto-CMD feature, both Auto-CMD12 and Auto-CMD23.
>>>> As a result, when Xenon SDHC slot can both support SD and SDIO, Auto-CMD12 is disabled when SDIO card is inserted, and renabled when SD is inserted.
>>>>
>>>> I recheck the sdhci code to set Auto-CMD bit in Transfer Mode register, in sdhci_set_transfer_mode():
>>>> if (mmc_op_multi(cmd->opcode) || data->blocks > 1)
>>>> As you can see, as long as it is CMD18/CMD25 OR there are multiple data blocks, Auto-CMD field will be set.
>>>> CMD53 doesn't have CMD23. Thus Auto-CMD12 is selected since Auto-CMD12 flag is set.
>>>> Thus I have to clear Auto-CMD12 to avoid issuing Auto-CMD12 in SDIO transfer.
>>>
>>>
>>> The code is:
>>>
>>> if (mmc_op_multi(cmd->opcode) || data->blocks > 1) {
>>> mode = SDHCI_TRNS_BLK_CNT_EN | SDHCI_TRNS_MULTI;
>>> /*
>>> * If we are sending CMD23, CMD12 never gets sent
>>> * on successful completion (so no Auto-CMD12).
>>> */
>>> if (sdhci_auto_cmd12(host, cmd->mrq) &&
>>> (cmd->opcode != SD_IO_RW_EXTENDED))
>>> mode |= SDHCI_TRNS_AUTO_CMD12;
>>> else if (cmd->mrq->sbc && (host->flags & SDHCI_AUTO_CMD23)) {
>>> mode |= SDHCI_TRNS_AUTO_CMD23;
>>> sdhci_writel(host, cmd->mrq->sbc->arg, SDHCI_ARGUMENT2);
>>> }
>>> }
>>>
>>> You can see the check for SD_IO_RW_EXTENDED which is CMD53.
>>>
>> Sorry. I didn't notice CMD53 check was added.
>> I introduced this Auto-CMD12 hack since kernel 3.8. It seems that this check is not added in kernel 3.8.
>> Thanks for the information. I will remove the Auto-CMD12 hack.
>>
>>>>
>>>> I just meet a similar issue in RPMB.
>>>> When Auto-CMD12 flag is set, eMMC RPMB access will trigger Auto-CMD12, since CMD25 is in use.
>>>> It will cause RPMB access failed.
>>>
>>> Can you explain more about the RPMB issue. Doesn't it use CMD23, so CMD12
>>> wouldn't be used - auto or manually.
>>>
>> RPMB go through the MMC ioctl routine.
>> Unlike normal data transfer, MMC ioctl for RPMB explicitly issues CMD23. When CMD25 is issued, there is neither data->sbc nor Auto-CMD23.
>> As a result, sdhci driver will automatically enable Auto-CMD12 for RPMB CMD25 if Auto-CMD12 flag is set.
>
> OK, so SDHCI should also not allow auto-cmd12 if there is no stop command
> i.e. data->stop is null.
>
data->stop and cmd->stop are forced to be NULL if Auto-CMD12 is enabled.
Instead, currently I use cmd->arg to check if it is a RPMB CMD25. If CMD25 argument is NULL, it should be RPMB access.
But I only verified it on Marvell platform. Please help check it when later I propose the formal patch.
>>
>>>>
>>>> One possible solution is to drop Auto-CMD12 support and use Auto-CMD23 only, in Xenon driver.
>>>> May I know you opinion, please?
>>>
>>> I don't use auto-CMD12 because I don't know if it provides any benefit and
>>> sdhci does not seem to have implemented Auto CMD12 Error Recovery, although
>>> I have never looked at it closely.
>>>
>> Actually, Auto-CMD23 is always used on our Xenon. Auto-CMD12 is not used at all.
>> But since this driver is a general one for all Marvell products, Auto-CMD12 is also supported in case that Auto-CMD23 is not available.
>>
>>
>
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Neil Armstrong @ 2016-10-18 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018115115.GF1641@makrotopia.org>
On 10/18/2016 01:51 PM, Daniel Golle wrote:
> Hi Neil,
>
> On Tue, Oct 18, 2016 at 01:24:22PM +0200, Neil Armstrong wrote:
>> On 10/18/2016 01:08 PM, Daniel Golle wrote:
>>> Hi Neil,
>>>
>>> great to see progress towards supporting OX820!
>>> The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
>>> looks very similar, see
>>>
>>> https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
>>>
>>> To me therefore this looks quite good, just one small question below.
>>
>> Hi Daniel,
>>
>> Yes, I work step by step, I hope to have something booting for 4.10 !
>>
>> Indeed, they look identical except the part_probes[] stuff, are they necessary ?
>
> Nah, this was dropped around kernel 4.7 from most drivers in favour of
> using the default partition probes (ie. cmdline and dt) afaik.
>
>>
>> My primary source of code was Ma Haiju's tree and OPenWRT's tree, but would some people like to push some of the openwrt driver upstream somehow ?
>
> I was planning this somehow, but lack the resources to seriously move
> forward. I've mostly been focussing on cleaning up Ma Haiju's code and
> improving support for the SATA driver (ie. adding support for both
> ports) and re-factoring the stmmac-based Ethernet driver to match the
> current kernel driver's style.
> However, I'm still using platform-specific includes (hardware.h) and
> thus look forward to rebase SATA and Ethernet support on top of your
> tree, as that would unluck ox820 support in multi-v6 instead of having
> a platform-specific kernel.
I made a fork of the SATA driver for the OX810SE who needs the external DMA
to work since it lacks the SATA-sgdma as used in OX820.
But it seems having Ethernet support would be easy, I can rework it and post it.
Yes, It would be great to sync with the upstream tree at some point, please tell
me how my work could be useful.
I only own a PogoPlug v3 to support the basic OX820, but I will lack hardware to
support PCIe and the dual SATA setup at some point.
The next work I plan to do once the basic OX820 boot is merged is to push the USB,
and the PLL support in the clock driver. The SATA and PCIe would be a natural following work.
>
> Currently there are problems with the NAND driver failing to detect the
> chip on non-PCIe platform like the PogoPlug V3 (non-Pro), MitraStar
> STG-212 and probably other non-PCIe boards which I didn't check yet.
> This magically happened when switching from kernel 4.1 to 4.4, I'm
> bisecting this since, but the problem seems to be hidden somewhere
> between the lines (ie. probe-order-related or such)...
> Did you test your NAND driver on any non-PCIe boards and did it work?
Actually I tested only on non-PCIe, since I only own a PogoPlug v3 (non-pro) and the
probe works perfectly on 4.9-rc1 :
[...]
nand: Could not find valid ONFI parameter page; aborting
nand: device found, Manufacturer ID: 0xad, Chip ID: 0xf1
nand: Hynix NAND 128MiB 3,3V 8-bit
nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
Scanning device for bad blocks
Bad eraseblock 511 at 0x000003fe0000
2 ofpart partitions found on MTD device 41000000.nand
Creating 2 MTD partitions on "41000000.nand":
0x000000000000-0x000000e00000 : "boot"
0x000000e00000-0x000008000000 : "ubi"
[...]
# ubiattach -p /dev/mtd1
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 9, need 19
ubi0: attached mtd1 (name "ubi", size 114 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 911, bad PEBs: 1, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 0
ubi0: available PEBs: 0, total reserved PEBs: 911, PEBs reserved for bad PEB handling: 9
ubi0: background thread "ubi_bgt0d" started, PID 824
UBI device number 0, total 911 LEBs (117540864 bytes, 112.1 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
[...]
>
>
> For a more or less complete history of the changes I made since
> branching of Ma Haijun's tree, see
>
> https://git.lede-project.org/?p=lede/dangole/staging.git;a=history;f=target/linux/oxnas;hb=refs/heads/oxnas-nand
>
> and for the very early history, prior to the merge into the official
> OpenWrt tree, see
>
> http://gitorious.org/openwrt-oxnas/openwrt-oxnas.git
>
Great, thanks for the hints.
I did set up a ML for the upstream work at linux-oxnas at lists.tuxfamily.org and a patchwork interface https://patchwork.kernel.org/project/linux-oxnas/list/ if it can be helpful.
I also idle on #linux-oxnas on freenode...
Neil
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ziji Hu @ 2016-10-18 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63e2bacf-6ad9-5e20-2c49-e77eb362ccfc@intel.com>
Hi Adrian,
On 2016/10/17 15:55, Adrian Hunter wrote:
> On 12/10/16 15:17, Ziji Hu wrote:
>> Hi Adrian,
>>
>> On 2016/10/11 20:39, Adrian Hunter wrote:
<snip>
>>>> +static int __xenon_emmc_delay_adj_test(struct mmc_card *card)
>>>> +{
>>>> + int err;
>>>> + u8 *ext_csd = NULL;
>>>> +
>>>> + err = mmc_get_ext_csd(card, &ext_csd);
>>>> + kfree(ext_csd);
>>>> +
>>>> + return err;
>>>> +}
>>>> +
>>>> +static int __xenon_sdio_delay_adj_test(struct mmc_card *card)
>>>> +{
>>>> + struct mmc_command cmd = {0};
>>>> + int err;
>>>> +
>>>> + cmd.opcode = SD_IO_RW_DIRECT;
>>>> + cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
>>>> +
>>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>>> + if (err)
>>>> + return err;
>>>> +
>>>> + if (cmd.resp[0] & R5_ERROR)
>>>> + return -EIO;
>>>> + if (cmd.resp[0] & R5_FUNCTION_NUMBER)
>>>> + return -EINVAL;
>>>> + if (cmd.resp[0] & R5_OUT_OF_RANGE)
>>>> + return -ERANGE;
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int __xenon_sd_delay_adj_test(struct mmc_card *card)
>>>> +{
>>>> + struct mmc_command cmd = {0};
>>>> + int err;
>>>> +
>>>> + cmd.opcode = MMC_SEND_STATUS;
>>>> + cmd.arg = card->rca << 16;
>>>> + cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
>>>> +
>>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>>> + return err;
>>>> +}
>>>> +
>>>> +static int xenon_delay_adj_test(struct mmc_card *card)
>>>> +{
>>>> + WARN_ON(!card);
>>>> + WARN_ON(!card->host);
>>>> +
>>>> + if (mmc_card_mmc(card))
>>>> + return __xenon_emmc_delay_adj_test(card);
>>>> + else if (mmc_card_sd(card))
>>>> + return __xenon_sd_delay_adj_test(card);
>>>> + else if (mmc_card_sdio(card))
>>>> + return __xenon_sdio_delay_adj_test(card);
>>>> + else
>>>> + return -EINVAL;
>>>> +}
>>>
>>> So you are issuing commands from the ->set_ios() callback. I would want to
>>> get Ulf's OK for that before going further.
>>>
>> Yes, you are correct.
>> In some speed mode, Xenon SDHC has to send a series of transfers to search for a perfect sampling point in PHY delay line.
>> It is like tuning process.
>>
>>> One thing: you will need to ensure you don't trigger get HS400 re-tuning
>>> because it will call back into ->set_ios().
>>>
>> Could you please make the term "HS400 re-tuning" more detailed?
>> In current MMC driver, "HS400 re-tuning" will go back to HS200, execute HS200 tuning and come back to HS400.
>> I'm sure our Xenon SDHC will not execute it.
>
> Currently, re-tuning is automatically enabled whenever tuning is executed,
> and then re-tuning will be done periodically or after CRC errors. The
> function to disable re-tuning mmc_retune_disable() is not exported, however
> if you have you are determining the sampling point your own way, you could
> simply not implement ->execute_tuning() and then there would be no tuning
> and no re-tuning.
>
It is a little complex in our Xenon SDHC.
For the speed mode which requests tuning, such as SDR104 and HS200, our driver will execute standard tuning as spec requires.
However, for those speed mode in which tuning is not requested in spec, our driver has to issues commands to search for the best sampling point.
It seems that HS400 re-tuning/tuning is disabled by default. Is it correct?
>>
>> However, in coming eMMC 5.2, there is a real HS400 re-tuning, in which tuning can be directly executed in HS400 mode.
>> Our Xenon SDHC will neither trigger this HS400 re-tuning.
>> But since so far there is no such feature in MMC driver, I cannot give you a 100% guarantee now.
>>
>>> And you have the problem that you need to get a reference to the card before
>>> the card device has been added. As I wrote in response to the previous
>>> patch, you should get Ulf's help with that too.
>>>
>> Sure.
>> I will get card_candidate solved at first.
>> Thank you again for your review and help.
>>
>> Thank you.
>>
>> Best regards,
>> Hu Ziji
>>>
>>
>
^ permalink raw reply
* [PATCH v7 0/5] ARM: dts: imx6q: Add Engicam i.CoreM6 dts
From: Jagan Teki @ 2016-10-18 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437243-13297-1-git-send-email-jteki@openedev.com>
Hi Shawn,
On Fri, Oct 14, 2016 at 2:57 PM, Jagan Teki <jteki@openedev.com> wrote:
> This is series add dts support for Engicam I.Core M6 qdl modules. just
> rebased on top of linux-next of previous set[1].
>
> [1] http://www.spinics.net/lists/kernel/msg2358233.html
>
> Jagan Teki (5):
> ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
> ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
> ARM: dts: imx6qdl-icore: Add usbhost support
> ARM: dts: imx6qdl-icore: Add usbotg support
> ARM: dts: imx6qdl-icore: Add FEC support
>
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx6dl-icore.dts | 59 ++++++++
> arch/arm/boot/dts/imx6q-icore.dts | 59 ++++++++
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 271 +++++++++++++++++++++++++++++++++++
> 4 files changed, 391 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
> create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
Can you pick this series?
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Daniel Golle @ 2016-10-18 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c377cb60-a359-62c1-dc6b-7b0be8b8e228@baylibre.com>
Hi Neil,
On Tue, Oct 18, 2016 at 01:24:22PM +0200, Neil Armstrong wrote:
> On 10/18/2016 01:08 PM, Daniel Golle wrote:
> > Hi Neil,
> >
> > great to see progress towards supporting OX820!
> > The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
> > looks very similar, see
> >
> > https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
> >
> > To me therefore this looks quite good, just one small question below.
>
> Hi Daniel,
>
> Yes, I work step by step, I hope to have something booting for 4.10 !
>
> Indeed, they look identical except the part_probes[] stuff, are they necessary ?
Nah, this was dropped around kernel 4.7 from most drivers in favour of
using the default partition probes (ie. cmdline and dt) afaik.
>
> My primary source of code was Ma Haiju's tree and OPenWRT's tree, but would some people like to push some of the openwrt driver upstream somehow ?
I was planning this somehow, but lack the resources to seriously move
forward. I've mostly been focussing on cleaning up Ma Haiju's code and
improving support for the SATA driver (ie. adding support for both
ports) and re-factoring the stmmac-based Ethernet driver to match the
current kernel driver's style.
However, I'm still using platform-specific includes (hardware.h) and
thus look forward to rebase SATA and Ethernet support on top of your
tree, as that would unluck ox820 support in multi-v6 instead of having
a platform-specific kernel.
Currently there are problems with the NAND driver failing to detect the
chip on non-PCIe platform like the PogoPlug V3 (non-Pro), MitraStar
STG-212 and probably other non-PCIe boards which I didn't check yet.
This magically happened when switching from kernel 4.1 to 4.4, I'm
bisecting this since, but the problem seems to be hidden somewhere
between the lines (ie. probe-order-related or such)...
Did you test your NAND driver on any non-PCIe boards and did it work?
For a more or less complete history of the changes I made since
branching of Ma Haijun's tree, see
https://git.lede-project.org/?p=lede/dangole/staging.git;a=history;f=target/linux/oxnas;hb=refs/heads/oxnas-nand
and for the very early history, prior to the merge into the official
OpenWrt tree, see
http://gitorious.org/openwrt-oxnas/openwrt-oxnas.git
Cheers
Daniel
>
> Thanks,
> Neil
>
> >
> > Cheers
> >
> > Daniel
> >
> >
> > On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
> >> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> >> This is a simple memory mapped NAND controller with single chip select and
> >> software ECC.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
> >> drivers/mtd/nand/Kconfig | 5 +
> >> drivers/mtd/nand/Makefile | 1 +
> >> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
> >> 4 files changed, 174 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> >> create mode 100644 drivers/mtd/nand/oxnas_nand.c
> >>
>
> [...]
>
> >> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
> >> new file mode 100644
> >> index 0000000..ee402ab
> >> --- /dev/null
> >> +++ b/drivers/mtd/nand/oxnas_nand.c
> >> @@ -0,0 +1,144 @@
> >> +/*
> >> + * Oxford Semiconductor OXNAS NAND driver
> >> + *
> >> + * Heavily based on plat_nand.c :
> >> + * Author: Vitaly Wool <vitalywool@gmail.com>
>
> Hmm, I forgot the OpenWRT and Ma Haijun copyrights here...
>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + */
> >> +
> >> +#include <linux/err.h>
> >> +#include <linux/io.h>
> >> +#include <linux/module.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/clk.h>
> >> +#include <linux/reset.h>
> >> +#include <linux/mtd/mtd.h>
> >> +#include <linux/mtd/nand.h>
> >> +#include <linux/mtd/partitions.h>
> >> +
> >> +/* nand commands */
> >> +#define NAND_CMD_ALE BIT(18)
> >> +#define NAND_CMD_CLE BIT(19)
> >> +#define NAND_CMD_CS 0
> >> +#define NAND_CMD_RESET 0xff
> >> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
> >> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
> >> +#define NAND_DATA (NAND_CMD_CS)
> >> +
> >> +struct oxnas_nand_data {
> >> + struct nand_chip chip;
> >> + void __iomem *io_base;
> >
> > Why do you redundantly keep io_base in platform data rather than
> > just using chip.IO_ADDR_R and >chip.IO_ADDR_W?
>
> For no reason since it's not used in oxnas_nand_cmd_ctrl...
> Will remove !
>
> >
> >
> >> + struct clk *clk;
> >> +};
> >> +
> >> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
> >> + unsigned int ctrl)
> >> +{
> >> + struct nand_chip *this = mtd->priv;
> >> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
> >> +
> >> + if (ctrl & NAND_CTRL_CHANGE) {
> >> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
> >> + if (ctrl & NAND_CLE)
> >> + nandaddr |= NAND_CMD;
> >> + else if (ctrl & NAND_ALE)
> >> + nandaddr |= NAND_ADDR;
> >> + this->IO_ADDR_W = (void __iomem *) nandaddr;
> >> + }
> >> +
> >> + if (cmd != NAND_CMD_NONE)
> >> + writeb(cmd, (void __iomem *) nandaddr);
> >> +}
> [...]
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Catalin Marinas @ 2016-10-18 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> fix is compatible with, not the patch that introduced the algorithm.
I think for future reference, the Fixes tag should denote the commit
that introduced the issue. An explicit Cc: stable tag would state how
far back it should be applied.
> Ard Biesheuvel (8):
> crypto: arm64/aes-ce - fix for big endian
> crypto: arm64/ghash-ce - fix for big endian
> crypto: arm64/sha1-ce - fix for big endian
> crypto: arm64/sha2-ce - fix for big endian
> crypto: arm64/aes-ccm-ce: fix for big endian
> crypto: arm64/aes-neon - fix for big endian
> crypto: arm64/aes-xts-ce: fix for big endian
> crypto: arm/aes-ce - fix for big endian
The changes look fine to me but I can't claim I fully understand these
algorithms. FWIW:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
(Will may pick them up for 4.9-rcX)
^ permalink raw reply
* [PATCH v2 4/4] cpufreq: pxa: convert to clock API
From: Viresh Kumar @ 2016-10-18 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-5-git-send-email-robert.jarzmik@free.fr>
On 15-10-16, 21:57, Robert Jarzmik wrote:
> As the clock settings have been introduced into the clock pxa drivers,
> which are now available to change the CPU clock by themselves, remove
> the clock handling from this driver, and rely on pxa clock drivers.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> Since v1: added !OF Kconfig dependency
> ---
> drivers/cpufreq/Kconfig.arm | 2 +-
> drivers/cpufreq/pxa2xx-cpufreq.c | 191 ++++++++-------------------------------
> 2 files changed, 40 insertions(+), 153 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: pxa: add pxa25x cpu operating points
From: Viresh Kumar @ 2016-10-18 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-3-git-send-email-robert.jarzmik@free.fr>
On 15-10-16, 21:57, Robert Jarzmik wrote:
> Add the relevant data taken from the PXA 25x Electrical, Mechanical, and
> Thermal Specfication. This will be input data for cpufreq-dt driver.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> arch/arm/boot/dts/pxa25x.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
> index 0d1e012178c4..16b4e8bad4a5 100644
> --- a/arch/arm/boot/dts/pxa25x.dtsi
> +++ b/arch/arm/boot/dts/pxa25x.dtsi
> @@ -89,4 +89,29 @@
> clocks = <&clktimer>;
> status = "okay";
> };
> +
> + pxa250_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> + opp at 99500 {
We have been keeping the values in ^^^ same as the values present
below. Any specific reason for making it different here ?
> + opp-hz = /bits/ 64 <99532800>;
> + opp-microvolt = <950000 1000000 1650000>;
> + clock-latency-ns = <20>;
> + };
> + opp at 199100 {
> + opp-hz = /bits/ 64 <199065600>;
> + opp-microvolt = <1000000 950000 1650000>;
> + clock-latency-ns = <20>;
> + };
> + opp at 298600 {
> + opp-hz = /bits/ 64 <298598400>;
> + opp-microvolt = <1100000 1045000 1650000>;
> + clock-latency-ns = <20>;
> + };
> + opp at 398100 {
> + opp-hz = /bits/ 64 <398131200>;
> + opp-microvolt = <1300000 1235000 1650000>;
> + clock-latency-ns = <20>;
> + };
> + };
> };
> --
> 2.1.4
--
viresh
^ permalink raw reply
* [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Viresh Kumar @ 2016-10-18 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-2-git-send-email-robert.jarzmik@free.fr>
On 15-10-16, 21:57, Robert Jarzmik wrote:
> For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is
> doing the job as well as pxa2xx-cpufreq, so add these platforms to the
> compatibility list.
>
> This won't work for legacy non device-tree platforms where
> pxa2xx-cpufreq is still required.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 0bb44d5b5df4..356825b5c9b8 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = {
> { .compatible = "fsl,imx7d", },
>
> { .compatible = "marvell,berlin", },
> + { .compatible = "marvell,pxa250", },
> + { .compatible = "marvell,pxa270", },
>
> { .compatible = "samsung,exynos3250", },
> { .compatible = "samsung,exynos4210", },
Isn't there a race between cpufreq-dt and the platform driver to
register first ?
Also, it seems that atleast the next two patches are required before
applying this? You need to fix the order if that is the case.
--
viresh
^ permalink raw reply
* [PATCH 1/2] iommu/mediatek: Convert M4Uv2 to iommu_fwspec
From: Yong Wu @ 2016-10-18 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0205bf6404b16bdebe8039bfc65570a2a6f9f960.1476704508.git.robin.murphy@arm.com>
On Mon, 2016-10-17 at 12:49 +0100, Robin Murphy wrote:
> Our per-device data consists of the M4U instance and firmware-provided
> list of LARB IDs, which is a perfect fit for the generic iommu_fwspec
> machinery. Use that directly as a simpler alternative to the custom
> archdata code.
>
> CC: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> These are fairly mechanical cleanups, so I'm pretty confident, but it
> still bears mentioning that they're only compile-tested as I don't have
> the relevant hardware.
Thanks for the improvement.
Tested-by: Yong Wu <yong.wu@mediatek.com>
>
> Robin.
>
> drivers/iommu/mtk_iommu.c | 75 ++++++++++++-----------------------------------
> 1 file changed, 18 insertions(+), 57 deletions(-)
>
[...]
^ permalink raw reply
* [PATCH 2/3] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Viresh Kumar @ 2016-10-18 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476629958-25368-3-git-send-email-yamada.masahiro@socionext.com>
On 16-10-16, 23:59, Masahiro Yamada wrote:
> + cluster0_opp: opp_table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp at 245000000 {
> + opp-hz = /bits/ 64 <245000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 250000000 {
> + opp-hz = /bits/ 64 <250000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 490000000 {
> + opp-hz = /bits/ 64 <490000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 653333333 {
Why isn't ^^ matching with below values ? Same in next patch as well.
> + opp-hz = /bits/ 64 <653334000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 666666666 {
> + opp-hz = /bits/ 64 <666667000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 980000000 {
> + opp-hz = /bits/ 64 <980000000>;
> + clock-latency-ns = <300>;
> + };
> + };
> +
> clocks {
> refclk: ref {
> compatible = "fixed-clock";
> --
> 1.9.1
--
viresh
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Neil Armstrong @ 2016-10-18 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018110807.GD1641@makrotopia.org>
On 10/18/2016 01:08 PM, Daniel Golle wrote:
> Hi Neil,
>
> great to see progress towards supporting OX820!
> The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
> looks very similar, see
>
> https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
>
> To me therefore this looks quite good, just one small question below.
Hi Daniel,
Yes, I work step by step, I hope to have something booting for 4.10 !
Indeed, they look identical except the part_probes[] stuff, are they necessary ?
My primary source of code was Ma Haiju's tree and OPenWRT's tree, but would some people like to push some of the openwrt driver upstream somehow ?
Thanks,
Neil
>
> Cheers
>
> Daniel
>
>
> On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
>> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
>> This is a simple memory mapped NAND controller with single chip select and
>> software ECC.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
>> drivers/mtd/nand/Kconfig | 5 +
>> drivers/mtd/nand/Makefile | 1 +
>> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
>> 4 files changed, 174 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
>> create mode 100644 drivers/mtd/nand/oxnas_nand.c
>>
[...]
>> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
>> new file mode 100644
>> index 0000000..ee402ab
>> --- /dev/null
>> +++ b/drivers/mtd/nand/oxnas_nand.c
>> @@ -0,0 +1,144 @@
>> +/*
>> + * Oxford Semiconductor OXNAS NAND driver
>> + *
>> + * Heavily based on plat_nand.c :
>> + * Author: Vitaly Wool <vitalywool@gmail.com>
Hmm, I forgot the OpenWRT and Ma Haijun copyrights here...
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/clk.h>
>> +#include <linux/reset.h>
>> +#include <linux/mtd/mtd.h>
>> +#include <linux/mtd/nand.h>
>> +#include <linux/mtd/partitions.h>
>> +
>> +/* nand commands */
>> +#define NAND_CMD_ALE BIT(18)
>> +#define NAND_CMD_CLE BIT(19)
>> +#define NAND_CMD_CS 0
>> +#define NAND_CMD_RESET 0xff
>> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
>> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
>> +#define NAND_DATA (NAND_CMD_CS)
>> +
>> +struct oxnas_nand_data {
>> + struct nand_chip chip;
>> + void __iomem *io_base;
>
> Why do you redundantly keep io_base in platform data rather than
> just using chip.IO_ADDR_R and >chip.IO_ADDR_W?
For no reason since it's not used in oxnas_nand_cmd_ctrl...
Will remove !
>
>
>> + struct clk *clk;
>> +};
>> +
>> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
>> + unsigned int ctrl)
>> +{
>> + struct nand_chip *this = mtd->priv;
>> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
>> +
>> + if (ctrl & NAND_CTRL_CHANGE) {
>> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
>> + if (ctrl & NAND_CLE)
>> + nandaddr |= NAND_CMD;
>> + else if (ctrl & NAND_ALE)
>> + nandaddr |= NAND_ADDR;
>> + this->IO_ADDR_W = (void __iomem *) nandaddr;
>> + }
>> +
>> + if (cmd != NAND_CMD_NONE)
>> + writeb(cmd, (void __iomem *) nandaddr);
>> +}
[...]
^ permalink raw reply
* [RFC] reduce latency in __purge_vmap_area_lazy
From: Jisheng Zhang @ 2016-10-18 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476773771-11470-1-git-send-email-hch@lst.de>
On Tue, 18 Oct 2016 08:56:05 +0200 Christoph Hellwig wrote:
> Hi all,
>
> this is my spin at sorting out the long lock hold times in
> __purge_vmap_area_lazy. It is based on the patch from Joel sent this
> week. I don't have any good numbers for it, but it survived an
> xfstests run on XFS which is a significant vmalloc user. The
> changelogs could still be improved as well, but I'd rather get it
> out quickly for feedback and testing.
I just tested this series, the preempt off ftrace log doesn't complain
__purge_vmap_area_lazy any more in my test case, this latency is removed!
So feel free to add
Tested-by: Jisheng Zhang <jszhang@marvell.com>
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index 5450367..3b23b32 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy at 2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index 064b322..5450367 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
Add documention of ti,min-output-impedance and ti,max-output-impedance
which can be used to correct MAC impedance mismatch using phy extended
registers.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+Optional property:
+ - ti,min-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ minimum value (35 ohms).
+ - ti,max-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
Default child nodes are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from v3:
* Fixup change log text and no code changes.
Changes from v2:
* Fixed a typo in dts and driver.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23343139/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v4
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: add phy impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.1.445.g3cdd5d1
^ permalink raw reply
* [PATCH v4 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Rongrong Zou @ 2016-10-18 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018074922.GZ20761@phenom.ffwll.local>
Hi Daniel,
Thanks for your review!
? 2016/10/18 15:49, Daniel Vetter ??:
> On Tue, Oct 18, 2016 at 12:01:18PM +0800, Rongrong Zou wrote:
>> Add support for fbdev and framebuffer.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 25 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 25 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 257 ++++++++++++++++++++++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 67 ++++++
>> 5 files changed, 375 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> index d5c40b8..810a37e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> @@ -1,5 +1,5 @@
>> ccflags-y := -Iinclude/drm
>> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o hibmc_ttm.o
>> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
>>
>> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
>> #obj-y += hibmc-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index e118f3b..8ddb763 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -66,11 +66,31 @@ static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>>
>> static int hibmc_pm_suspend(struct device *dev)
>> {
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>> +
>> + if (hidev->fbdev.initialized) {
>
> What do you need these checks for? This looks a bit fishy tbh ...
It is delivered from the bochs driver, and I will fix if there are
any problems, Thanks.
>
>> + console_lock();
>> + drm_fb_helper_set_suspend(&hidev->fbdev.helper, 1);
>> + console_unlock();
>
> drm_fb_helper_set_suspend_unlocked is the new fancy one. Please use that
> one instead. Also, that has the check you might need already included,
> which means you can nuke this entire function here and just call it
> directly.
So it should be wrote as:
static int hibmc_pm_suspend(struct device *dev)
{
...
drm_kms_helper_poll_disable(drm_dev);
drm_fb_helper_set_suspend_unlocked(&hidev->fbdev.helper, 1);
...
}
static int hibmc_pm_resume(struct device *dev)
{
...
drm_helper_resume_force_mode(drm_dev);
drm_fb_helper_set_suspend_unlocked(&hidev->fbdev.helper, 0);
drm_kms_helper_poll_enable(drm_dev);
...
}, is it ?
Regards
Rongrong.
> -Daniel
>
>> + }
>> +
>> return 0;
>> }
>>
>> static int hibmc_pm_resume(struct device *dev)
>> {
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>> +
>> + if (hidev->fbdev.initialized) {
>> + console_lock();
>> + drm_fb_helper_set_suspend(&hidev->fbdev.helper, 0);
>> + console_unlock();
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -170,6 +190,7 @@ static int hibmc_unload(struct drm_device *dev)
>> {
>> struct hibmc_drm_device *hidev = dev->dev_private;
>>
>> + hibmc_fbdev_fini(hidev);
>> hibmc_hw_fini(hidev);
>> dev->dev_private = NULL;
>> return 0;
>> @@ -194,6 +215,10 @@ static int hibmc_load(struct drm_device *dev, unsigned long flags)
>> if (ret)
>> goto err;
>>
>> + ret = hibmc_fbdev_init(hidev);
>> + if (ret)
>> + goto err;
>> +
>> return 0;
>>
>> err:
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 00bb153..4f5887f 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -20,9 +20,23 @@
>> #define HIBMC_DRM_DRV_H
>>
>> #include <drm/drmP.h>
>> +#include <drm/drm_fb_helper.h>
>> #include <drm/ttm/ttm_bo_driver.h>
>> #include <drm/drm_gem.h>
>>
>> +struct hibmc_framebuffer {
>> + struct drm_framebuffer fb;
>> + struct drm_gem_object *obj;
>> + bool is_fbdev_fb;
>> +};
>> +
>> +struct hibmc_fbdev {
>> + struct drm_fb_helper helper;
>> + struct hibmc_framebuffer fb;
>> + int size;
>> + bool initialized;
>> +};
>> +
>> struct hibmc_drm_device {
>> /* hw */
>> void __iomem *mmio;
>> @@ -41,9 +55,13 @@ struct hibmc_drm_device {
>> bool initialized;
>> } ttm;
>>
>> + /* fbdev */
>> + struct hibmc_fbdev fbdev;
>> bool mm_inited;
>> };
>>
>> +#define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer, fb)
>> +
>> struct hibmc_bo {
>> struct ttm_buffer_object bo;
>> struct ttm_placement placement;
>> @@ -65,8 +83,15 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>>
>> #define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT)
>>
>> +int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> +void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>> +
>> int hibmc_gem_create(struct drm_device *dev, u32 size, bool iskernel,
>> struct drm_gem_object **obj);
>> +int hibmc_framebuffer_init(struct drm_device *dev,
>> + struct hibmc_framebuffer *gfb,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object *obj);
>>
>> int hibmc_mm_init(struct hibmc_drm_device *hibmc);
>> int hibmc_bo_pin(struct hibmc_bo *bo, u32 pl_flag, u64 *gpu_addr);
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>> new file mode 100644
>> index 0000000..ea2d86a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>> @@ -0,0 +1,257 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#include <drm/drm_crtc.h>
>> +#include <drm/drm_crtc_helper.h>
>> +#include <drm/drm_fb_helper.h>
>> +
>> +#include "hibmc_drm_drv.h"
>> +
>> +/* ---------------------------------------------------------------------- */
>> +
>> +static int hibmcfb_create_object(
>> + struct hibmc_drm_device *hidev,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object **gobj_p)
>> +{
>> + struct drm_gem_object *gobj;
>> + struct drm_device *dev = hidev->dev;
>> + u32 size;
>> + int ret = 0;
>> +
>> + size = mode_cmd->pitches[0] * mode_cmd->height;
>> + ret = hibmc_gem_create(dev, size, true, &gobj);
>> + if (ret)
>> + return ret;
>> +
>> + *gobj_p = gobj;
>> + return ret;
>> +}
>> +
>> +static struct fb_ops hibmc_drm_fb_ops = {
>> + .owner = THIS_MODULE,
>> + .fb_check_var = drm_fb_helper_check_var,
>> + .fb_set_par = drm_fb_helper_set_par,
>> + .fb_fillrect = drm_fb_helper_sys_fillrect,
>> + .fb_copyarea = drm_fb_helper_sys_copyarea,
>> + .fb_imageblit = drm_fb_helper_sys_imageblit,
>> + .fb_pan_display = drm_fb_helper_pan_display,
>> + .fb_blank = drm_fb_helper_blank,
>> + .fb_setcmap = drm_fb_helper_setcmap,
>> +};
>> +
>> +static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
>> + struct drm_fb_helper_surface_size *sizes)
>> +{
>> + struct hibmc_fbdev *gfbdev =
>> + container_of(helper, struct hibmc_fbdev, helper);
>> + struct hibmc_drm_device *hidev =
>> + container_of(helper, struct hibmc_drm_device, fbdev.helper);
>> + struct fb_info *info;
>> + struct drm_framebuffer *fb;
>> + struct drm_mode_fb_cmd2 mode_cmd;
>> + struct drm_gem_object *gobj = NULL;
>> + int ret = 0;
>> + size_t size;
>> + unsigned int bytes_per_pixel;
>> + struct hibmc_bo *bo = NULL;
>> +
>> + DRM_DEBUG_DRIVER("surface width(%d), height(%d) and bpp(%d)\n",
>> + sizes->surface_width, sizes->surface_height,
>> + sizes->surface_bpp);
>> + sizes->surface_depth = 32;
>> +
>> + bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
>> +
>> + mode_cmd.width = sizes->surface_width;
>> + mode_cmd.height = sizes->surface_height;
>> + mode_cmd.pitches[0] = mode_cmd.width * bytes_per_pixel;
>> + mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
>> + sizes->surface_depth);
>> +
>> + size = roundup(mode_cmd.pitches[0] * mode_cmd.height, PAGE_SIZE);
>> +
>> + ret = hibmcfb_create_object(hidev, &mode_cmd, &gobj);
>> + if (ret) {
>> + DRM_ERROR("failed to create fbcon backing object %d\r\n", ret);
>> + return -ENOMEM;
>> + }
>> +
>> + bo = gem_to_hibmc_bo(gobj);
>> +
>> + ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
>> + if (ret)
>> + return ret;
>> +
>> + ret = hibmc_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
>> + if (ret) {
>> + DRM_ERROR("failed to pin fbcon\n");
>> + return ret;
>> + }
>> +
>> + ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
>> +
>> + if (ret) {
>> + DRM_ERROR("failed to kmap fbcon\n");
>> + ttm_bo_unreserve(&bo->bo);
>> + return ret;
>> + }
>> +
>> + ttm_bo_unreserve(&bo->bo);
>> +
>> + info = drm_fb_helper_alloc_fbi(helper);
>> + if (IS_ERR(info))
>> + ret = PTR_ERR(info);
>> +
>> + info->par = gfbdev;
>> +
>> + ret = hibmc_framebuffer_init(hidev->dev, &hidev->fbdev.fb,
>> + &mode_cmd, gobj);
>> + if (ret) {
>> + drm_fb_helper_release_fbi(helper);
>> + return ret;
>> + }
>> +
>> + hidev->fbdev.size = size;
>> + fb = &gfbdev->fb.fb;
>> + if (!fb) {
>> + DRM_INFO("fb is NULL\n");
>> + return -EINVAL;
>> + }
>> +
>> + gfbdev->helper.fb = fb;
>> +
>> + strcpy(info->fix.id, "hibmcdrmfb");
>> +
>> + info->flags = FBINFO_DEFAULT;
>> + info->fbops = &hibmc_drm_fb_ops;
>> +
>> + drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
>> + drm_fb_helper_fill_var(info, &hidev->fbdev.helper, sizes->fb_width,
>> + sizes->fb_height);
>> +
>> + info->screen_base = bo->kmap.virtual;
>> + info->screen_size = size;
>> +
>> + info->fix.smem_start = bo->bo.mem.bus.offset + bo->bo.mem.bus.base;
>> + info->fix.smem_len = size;
>> +
>> + return 0;
>> +}
>> +
>> +static int hibmc_fbdev_destroy(struct drm_device *dev,
>> + struct hibmc_fbdev *fbdev)
>> +{
>> + struct hibmc_framebuffer *gfb = &fbdev->fb;
>> + struct drm_fb_helper *fbh = &fbdev->helper;
>> +
>> + DRM_DEBUG_DRIVER("hibmc_fbdev_destroy\n");
>> +
>> + drm_fb_helper_unregister_fbi(fbh);
>> + drm_fb_helper_release_fbi(fbh);
>> +
>> + if (gfb->obj) {
>> + drm_gem_object_unreference_unlocked(gfb->obj);
>> + gfb->obj = NULL;
>> + }
>> +
>> + drm_fb_helper_fini(fbh);
>> +
>> + drm_framebuffer_unregister_private(&gfb->fb);
>> + drm_framebuffer_cleanup(&gfb->fb);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct drm_fb_helper_funcs hibmc_fbdev_helper_funcs = {
>> + .fb_probe = hibmc_drm_fb_create,
>> +};
>> +
>> +int hibmc_fbdev_init(struct hibmc_drm_device *hidev)
>> +{
>> + int ret;
>> + struct fb_var_screeninfo *var;
>> + struct fb_fix_screeninfo *fix;
>> +
>> + drm_fb_helper_prepare(hidev->dev, &hidev->fbdev.helper,
>> + &hibmc_fbdev_helper_funcs);
>> +
>> + /* Now just one crtc and one channel */
>> + ret = drm_fb_helper_init(hidev->dev,
>> + &hidev->fbdev.helper, 1, 1);
>> +
>> + if (ret)
>> + return ret;
>> +
>> + ret = drm_fb_helper_single_add_all_connectors(&hidev->fbdev.helper);
>> + if (ret)
>> + goto fini;
>> +
>> + ret = drm_fb_helper_initial_config(&hidev->fbdev.helper, 16);
>> + if (ret)
>> + goto fini;
>> +
>> + hidev->fbdev.initialized = true;
>> +
>> + var = &hidev->fbdev.helper.fbdev->var;
>> + fix = &hidev->fbdev.helper.fbdev->fix;
>> +
>> + DRM_DEBUG("Member of info->var is :\n"
>> + "xres=%d\n"
>> + "yres=%d\n"
>> + "xres_virtual=%d\n"
>> + "yres_virtual=%d\n"
>> + "xoffset=%d\n"
>> + "yoffset=%d\n"
>> + "bits_per_pixel=%d\n"
>> + "...\n", var->xres, var->yres, var->xres_virtual,
>> + var->yres_virtual, var->xoffset, var->yoffset,
>> + var->bits_per_pixel);
>> + DRM_DEBUG("Member of info->fix is :\n"
>> + "smem_start=%lx\n"
>> + "smem_len=%d\n"
>> + "type=%d\n"
>> + "type_aux=%d\n"
>> + "visual=%d\n"
>> + "xpanstep=%d\n"
>> + "ypanstep=%d\n"
>> + "ywrapstep=%d\n"
>> + "line_length=%d\n"
>> + "accel=%d\n"
>> + "capabilities=%d\n"
>> + "...\n", fix->smem_start, fix->smem_len, fix->type,
>> + fix->type_aux, fix->visual, fix->xpanstep,
>> + fix->ypanstep, fix->ywrapstep, fix->line_length,
>> + fix->accel, fix->capabilities);
>> +
>> + return 0;
>> +
>> +fini:
>> + drm_fb_helper_fini(&hidev->fbdev.helper);
>> + return ret;
>> +}
>> +
>> +void hibmc_fbdev_fini(struct hibmc_drm_device *hidev)
>> +{
>> + if (!hidev->fbdev.initialized)
>> + return;
>> +
>> + hibmc_fbdev_destroy(hidev->dev, &hidev->fbdev);
>> + hidev->fbdev.initialized = false;
>> +}
>> +
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> index 2dbef04..c8f7f6c 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> @@ -489,3 +489,70 @@ int hibmc_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
>> return 0;
>> }
>>
>> +/* ---------------------------------------------------------------------- */
>> +
>> +static void hibmc_user_framebuffer_destroy(struct drm_framebuffer *fb)
>> +{
>> + struct hibmc_framebuffer *hibmc_fb = to_hibmc_framebuffer(fb);
>> +
>> + drm_gem_object_unreference_unlocked(hibmc_fb->obj);
>> + drm_framebuffer_cleanup(fb);
>> + kfree(fb);
>> +}
>> +
>> +static const struct drm_framebuffer_funcs hibmc_fb_funcs = {
>> + .destroy = hibmc_user_framebuffer_destroy,
>> +};
>> +
>> +int hibmc_framebuffer_init(struct drm_device *dev,
>> + struct hibmc_framebuffer *gfb,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object *obj)
>> +{
>> + int ret;
>> +
>> + drm_helper_mode_fill_fb_struct(&gfb->fb, mode_cmd);
>> + gfb->obj = obj;
>> + ret = drm_framebuffer_init(dev, &gfb->fb, &hibmc_fb_funcs);
>> + if (ret) {
>> + DRM_ERROR("drm_framebuffer_init failed: %d\n", ret);
>> + return ret;
>> + }
>> + return 0;
>> +}
>> +
>> +static struct drm_framebuffer *
>> +hibmc_user_framebuffer_create(struct drm_device *dev,
>> + struct drm_file *filp,
>> + const struct drm_mode_fb_cmd2 *mode_cmd)
>> +{
>> + struct drm_gem_object *obj;
>> + struct hibmc_framebuffer *hibmc_fb;
>> + int ret;
>> +
>> + DRM_DEBUG_DRIVER("%dx%d, format %c%c%c%c\n",
>> + mode_cmd->width, mode_cmd->height,
>> + (mode_cmd->pixel_format) & 0xff,
>> + (mode_cmd->pixel_format >> 8) & 0xff,
>> + (mode_cmd->pixel_format >> 16) & 0xff,
>> + (mode_cmd->pixel_format >> 24) & 0xff);
>> +
>> + obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
>> + if (!obj)
>> + return ERR_PTR(-ENOENT);
>> +
>> + hibmc_fb = kzalloc(sizeof(*hibmc_fb), GFP_KERNEL);
>> + if (!hibmc_fb) {
>> + drm_gem_object_unreference_unlocked(obj);
>> + return ERR_PTR(-ENOMEM);
>> + }
>> +
>> + ret = hibmc_framebuffer_init(dev, hibmc_fb, mode_cmd, obj);
>> + if (ret) {
>> + drm_gem_object_unreference_unlocked(obj);
>> + kfree(hibmc_fb);
>> + return ERR_PTR(ret);
>> + }
>> + return &hibmc_fb->fb;
>> +}
>> +
>> --
>> 1.9.1
>>
>
^ permalink raw reply
* [PATCH] arm64: Cortex-A53 errata workaround: check for kernel addresses
From: Andre Przywara @ 2016-10-18 11:16 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
errata-affected core") adds code to execute cache maintenance instructions
in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
It turns out that the address hasn't been checked to be a valid user
space address, allowing userland to clean cache lines in kernel space.
Fix this by introducing an access_ok() check before executing the
instructions on behalf of userland, taking care of tagged pointers on
the way.
Reported-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Cc: <stable@vger.kernel.org> # 4.8.x
---
arch/arm64/include/asm/uaccess.h | 4 ++++
arch/arm64/kernel/traps.c | 32 ++++++++++++++++++++++++++++----
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index bcaf6fb..f842b47 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -21,6 +21,7 @@
/*
* User space memory access functions
*/
+#include <linux/bitops.h>
#include <linux/kasan-checks.h>
#include <linux/string.h>
#include <linux/thread_info.h>
@@ -103,6 +104,9 @@ static inline void set_fs(mm_segment_t fs)
})
#define access_ok(type, addr, size) __range_ok(addr, size)
+#define access_ok_tagged(type, addr, size) access_ok(type, \
+ sign_extend64(addr, 55), \
+ size)
#define user_addr_max get_fs
#define _ASM_EXTABLE(from, to) \
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5ff020f..04ea0d7 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -447,6 +447,30 @@ void cpu_enable_cache_maint_trap(void *__unused)
: "=r" (res) \
: "r" (address), "i" (-EFAULT) )
+enum {USER_CACHE_MAINT_DC_CIVAC, USER_CACHE_MAINT_IC_IVAU};
+
+static int do_user_cache_maint(int ins_type, unsigned long address)
+{
+ int ret;
+ unsigned long cl_size = cache_line_size();
+
+ if (!access_ok_tagged(VERIFY_READ,
+ round_down(address, cl_size),
+ cl_size))
+ return -EFAULT;
+
+ switch (ins_type) {
+ case USER_CACHE_MAINT_DC_CIVAC:
+ __user_cache_maint("dc civac", address, ret);
+ break;
+ case USER_CACHE_MAINT_IC_IVAU:
+ __user_cache_maint("ic ivau", address, ret);
+ break;
+ }
+
+ return ret;
+}
+
static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
{
unsigned long address;
@@ -458,16 +482,16 @@ static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
switch (crm) {
case ESR_ELx_SYS64_ISS_CRM_DC_CVAU: /* DC CVAU, gets promoted */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_DC_CVAC: /* DC CVAC, gets promoted */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_DC_CIVAC: /* DC CIVAC */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_IC_IVAU: /* IC IVAU */
- __user_cache_maint("ic ivau", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_IC_IVAU, address);
break;
default:
force_signal_inject(SIGILL, ILL_ILLOPC, regs, 0);
--
2.9.0
^ permalink raw reply related
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Daniel Golle @ 2016-10-18 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018090927.1990-1-narmstrong@baylibre.com>
Hi Neil,
great to see progress towards supporting OX820!
The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
looks very similar, see
https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
To me therefore this looks quite good, just one small question below.
Cheers
Daniel
On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> This is a simple memory mapped NAND controller with single chip select and
> software ECC.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
> drivers/mtd/nand/Kconfig | 5 +
> drivers/mtd/nand/Makefile | 1 +
> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
> 4 files changed, 174 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> create mode 100644 drivers/mtd/nand/oxnas_nand.c
>
> diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> new file mode 100644
> index 0000000..83b684d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> @@ -0,0 +1,24 @@
> +* Oxford Semiconductor OXNAS NAND Controller
> +
> +Please refer to nand.txt for generic information regarding MTD NAND bindings.
> +
> +Required properties:
> + - compatible: "oxsemi,ox820-nand"
> + - reg: Base address and length for NAND mapped memory.
> +
> +Optional Properties:
> + - clocks: phandle to the NAND gate clock if needed.
> + - resets: phandle to the NAND reset control if needed.
> +
> +Example:
> +
> +nand: nand at 41000000 {
> + compatible = "oxsemi,ox820-nand";
> + reg = <0x41000000 0x100000>;
> + nand-ecc-mode = "soft";
> + clocks = <&stdclk CLK_820_NAND>;
> + resets = <&reset RESET_NAND>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + status = "disabled";
> +};
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 7b7a887..c023125 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -426,6 +426,11 @@ config MTD_NAND_ORION
> No board specific support is done by this driver, each board
> must advertise a platform_device for the driver to attach.
>
> +config MTD_NAND_OXNAS
> + tristate "NAND Flash support for Oxford Semiconductor SoC"
> + help
> + This enables the NAND flash controller on Oxford Semiconductor SoCs.
> +
> config MTD_NAND_FSL_ELBC
> tristate "NAND support for Freescale eLBC controllers"
> depends on FSL_SOC
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index cafde6f..05fc054 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_MTD_NAND_TMIO) += tmio_nand.o
> obj-$(CONFIG_MTD_NAND_PLATFORM) += plat_nand.o
> obj-$(CONFIG_MTD_NAND_PASEMI) += pasemi_nand.o
> obj-$(CONFIG_MTD_NAND_ORION) += orion_nand.o
> +obj-$(CONFIG_MTD_NAND_OXNAS) += oxnas_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_ELBC) += fsl_elbc_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_IFC) += fsl_ifc_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_UPM) += fsl_upm.o
> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
> new file mode 100644
> index 0000000..ee402ab
> --- /dev/null
> +++ b/drivers/mtd/nand/oxnas_nand.c
> @@ -0,0 +1,144 @@
> +/*
> + * Oxford Semiconductor OXNAS NAND driver
> + *
> + * Heavily based on plat_nand.c :
> + * Author: Vitaly Wool <vitalywool@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/nand.h>
> +#include <linux/mtd/partitions.h>
> +
> +/* nand commands */
> +#define NAND_CMD_ALE BIT(18)
> +#define NAND_CMD_CLE BIT(19)
> +#define NAND_CMD_CS 0
> +#define NAND_CMD_RESET 0xff
> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
> +#define NAND_DATA (NAND_CMD_CS)
> +
> +struct oxnas_nand_data {
> + struct nand_chip chip;
> + void __iomem *io_base;
Why do you redundantly keep io_base in platform data rather than
just using chip.IO_ADDR_R and >chip.IO_ADDR_W?
> + struct clk *clk;
> +};
> +
> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
> + unsigned int ctrl)
> +{
> + struct nand_chip *this = mtd->priv;
> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
> +
> + if (ctrl & NAND_CTRL_CHANGE) {
> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
> + if (ctrl & NAND_CLE)
> + nandaddr |= NAND_CMD;
> + else if (ctrl & NAND_ALE)
> + nandaddr |= NAND_ADDR;
> + this->IO_ADDR_W = (void __iomem *) nandaddr;
> + }
> +
> + if (cmd != NAND_CMD_NONE)
> + writeb(cmd, (void __iomem *) nandaddr);
> +}
> +
> +/*
> + * Probe for the NAND device.
> + */
> +static int oxnas_nand_probe(struct platform_device *pdev)
> +{
> + struct oxnas_nand_data *data;
> + struct mtd_info *mtd;
> + struct resource *res;
> + int err = 0;
> +
> + /* Allocate memory for the device structure (and zero it) */
> + data = devm_kzalloc(&pdev->dev, sizeof(struct oxnas_nand_data),
> + GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + data->io_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(data->io_base))
> + return PTR_ERR(data->io_base);
> +
> + data->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(data->clk))
> + data->clk = NULL;
> +
> + nand_set_flash_node(&data->chip, pdev->dev.of_node);
> + mtd = nand_to_mtd(&data->chip);
> + mtd->dev.parent = &pdev->dev;
> + mtd->priv = &data->chip;
> +
> + data->chip.IO_ADDR_R = data->io_base;
> + data->chip.IO_ADDR_W = data->io_base;
> + data->chip.cmd_ctrl = oxnas_nand_cmd_ctrl;
> + data->chip.chip_delay = 30;
> + data->chip.ecc.mode = NAND_ECC_SOFT;
> + data->chip.ecc.algo = NAND_ECC_HAMMING;
> +
> + platform_set_drvdata(pdev, data);
> +
> + clk_prepare_enable(data->clk);
> + device_reset_optional(&pdev->dev);
> +
> + /* Scan to find existence of the device */
> + if (nand_scan(mtd, 1)) {
> + err = -ENXIO;
> + goto out;
> + }
> +
> + err = mtd_device_parse_register(mtd, NULL, NULL, NULL, 0);
> + if (!err)
> + return err;
> +
> + nand_release(mtd);
> +out:
> + return err;
> +}
> +
> +static int oxnas_nand_remove(struct platform_device *pdev)
> +{
> + struct oxnas_nand_data *data = platform_get_drvdata(pdev);
> +
> + nand_release(nand_to_mtd(&data->chip));
> +
> + return 0;
> +}
> +
> +static const struct of_device_id oxnas_nand_match[] = {
> + { .compatible = "oxsemi,ox820-nand" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, oxnas_nand_match);
> +
> +static struct platform_driver oxnas_nand_driver = {
> + .probe = oxnas_nand_probe,
> + .remove = oxnas_nand_remove,
> + .driver = {
> + .name = "oxnas_nand",
> + .of_match_table = oxnas_nand_match,
> + },
> +};
> +
> +module_platform_driver(oxnas_nand_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Vitaly Wool");
> +MODULE_DESCRIPTION("Oxnas NAND driver");
> +MODULE_ALIAS("platform:oxnas_nand");
> --
> 2.7.0
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Sudeep Holla @ 2016-10-18 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018104539.GB15639@leverpostej>
On 18/10/16 11:45, Mark Rutland wrote:
> On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
>>>> b. in arm64, if some platform has its own suspend flow, couldn't it
>>>> adopts arm/match-xxx to register its own global suspend method?
>>>
>>> No, PSCI is highly recommended.
>>
>> Relying on firmware for suspend on x86 was a great disaster, lets not repeat
>> that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
>> for example) -- feel free to copy that code from arm32.
>
> Quite frankly, copying hundreds of lines of board-specific code
> (including assembly that won't compile) is unlikely to help.
>
> So far arm64 requires well-defined, standard, reusable interfaces (e.g.
> PSCI). That cleanly separates concerns (e.g. anyone can implement the
> backend without mandatory changes to the kernel), and keeps things
> maintainable.
>
> ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
> can use and build atop of. It's open source (three-clause BSD with DCO),
> and accepts board ports. You can have a completely open stack,
> regardless of whether part of that stack is firmware.
>
I think you missed to add the link[1]
--
Regards,
Sudeep
[1] https://github.com/ARM-software/arm-trusted-firmware
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-18 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
On 11 October 2016 at 19:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> fix is compatible with, not the patch that introduced the algorithm. This is due
> to the fact that the key schedules are incompatible between generic AES and the
> arm64 Crypto Extensions implementation (but only when building for big endian)
> This is not a problem in practice, but it does mean that the AES-CCM and AES in
> EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
> one that is compatible with the generic AES key schedule generation code (which
> it currently no longer uses)
>
> In any case, please apply with cc to stable.
>
Ping?
> Ard Biesheuvel (8):
> crypto: arm64/aes-ce - fix for big endian
> crypto: arm64/ghash-ce - fix for big endian
> crypto: arm64/sha1-ce - fix for big endian
> crypto: arm64/sha2-ce - fix for big endian
> crypto: arm64/aes-ccm-ce: fix for big endian
> crypto: arm64/aes-neon - fix for big endian
> crypto: arm64/aes-xts-ce: fix for big endian
> crypto: arm/aes-ce - fix for big endian
>
> arch/arm/crypto/aes-ce-glue.c | 5 ++
> arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
> arch/arm64/crypto/aes-ce-cipher.c | 25 +++++----
> arch/arm64/crypto/aes-ce.S | 1 +
> arch/arm64/crypto/aes-modes.S | 3 +-
> arch/arm64/crypto/aes-neon.S | 25 +++++----
> arch/arm64/crypto/ghash-ce-core.S | 6 +--
> arch/arm64/crypto/sha1-ce-core.S | 4 +-
> arch/arm64/crypto/sha2-ce-core.S | 4 +-
> 9 files changed, 72 insertions(+), 54 deletions(-)
>
> --
> 2.7.4
>
^ 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