Hi.
Here is a trace:
amixer D 8068ae98 0 197183 0x
Backtrace:
[<8068ab7c>] (__schedule) from [<8068b1c4>] (schedule+0xb8/0xd0)
[<8068b10c>] (schedule) from [<8068b61c>] (schedule_preempt_disabled+0x20/0x2c)
[<8068b5fc>] (schedule_preempt_disabled) from [<8068cd18>]
(_
from [<8020a5ec>] (do_vfs_ioctl+0x7b0/0x884)
[<80209e3c>] (do_vfs_ioctl) from [<8020a704>] (SyS_ioctl+0x44/0x6c)
[<8020a6c0>] (SyS_ioctl) from [<80107900>] (ret_fast_syscall+0x0/0x3c)
Fix that by calling map->cache_ops->drop() directly.
Signed-off-by: Nikita Yu
>> Hi.
>>
>> Here is a trace:
>
> Please don't send cover letters for single patches, if there is anything
> that needs saying put it in the changelog of the patch or after the ---
> if it's administrative stuff. This reduces mail volume and ensures that
> any important information is recorded i
.
Move regcache calls to tpa6130a2_power() to get them at driver init time
as well.
Signed-off-by: Nikita Yushchenko
---
sound/soc/codecs/tpa6130a2.c | 49 +++-
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b
n, aic31xx-specific, and dac31xx-specific parts. Only parts
that match actual hardware (as declared in "compatible" device tree
property) are registered.
Signed-off-by: Nikita Yushchenko
---
sound/soc/codecs/tlv320aic31xx.c | 212 ---
sound/soc/codecs/t
clocks = ...
};
This describes audio path from IMX6 SSI2 through TLV320DAC3100 codec
through TPA6130A2 amplifier to headphones.
Signed-off-by: Nikita Yushchenko
---
.../devicetree/bindings/sound/simple-card.txt | 2 ++
sound/soc/generic/simple-card.c
Hi
> This case, I think you want ...
>
> simple-audio-card,codec {
> - sound-dai = <&codec1>;
> + sound-dai = <&codec>;
Oops... sure, thanks for noticing it.
>>a microphone is attached.
>> +- simple-audio-card,aux-devs
This patch makes it possible to use simple-card in setups where separate
amplifier chip is connected to codec's output.
Changes from v1:
- moved example usage from commit message to Documentation/, as
suggested by Kuninori Morimoto,
- fixed typo in example usage.
Signed-off-by: N
omponent on tlv320aic31xx" commit.
Signed-off-by: Nikita Yushchenko
---
.../devicetree/bindings/sound/tlv320aic31xx.txt| 9 +-
sound/soc/codecs/tlv320aic31xx.c | 212 +++--
sound/soc/codecs/tlv320aic31xx.h | 2 +
3 files changed, 1
>> Changes from v1:
>> - moved example usage from commit message to Documentation/, as
>> suggested by Kuninori Morimoto,
>> - fixed typo in example usage.
>
> Ah, one more property to the "simple" card. At what point in adding
> properties is it not simple?
AFAIU, idea is to have a pure-devic
Add device tree property to define auxiliary devices to be added to
simle-audio-card.
Together with proper audio routing definition, this allows to use
simple-card in setups where separate amplifier chip is connected to
codec's output.
Signed-off-by: Nikita Yushchenko
---
Rebased against c
Code undo operations in power enable errror path explicitly, instead of
reusing power disable path and playing with return values there.
Signed-off-by: Nikita Yushchenko
---
I doubt that copying 7 lines into error path is better than having a tiny
logic with return values, but still here it is
>> I doubt that copying 7 lines into error path is better than having a tiny
>> logic with return values, but still here it is.
>
> Consider what happens if someone wants to change the code...
I believe that "undo poweron" and "poweroff" sequences still will have
to remain the same. This having
This hardware supports only 2-channel DAI, even mono ADC digital output
has two channels with the same data.
Having min_channels=1 results in broken playback of mono files in setups
where CPU DAI supports mono.
Signed-off-by: Nikita Yushchenko
---
sound/soc/codecs/tlv320aic31xx.c | 6 +++---
1
t, maybe one can be implemented? I.e. by moving "tails" from
alloc_pages_exact() to a different free list to be used only when
no other pages are available?
WBR,
Nikita Yushchenko
Node 0, zone DMA 2 1 6 10 26 54 60 3
1 2 0 2 0
> I'm having a guess that this can be caused by use of
> alloc_pages_exact() for NoMMU private anonymous mappings.
>
> This routine causes "tail" of allocation to be returned back
> to allocator... and inserted at top of free list. Later, when
> whatever in the system makes a trivial order-0 alloc
>> Still, isn't there subsystem-level default that all events are disabled
>> by default? If such, then current hi8435 state breaks subsystem-level
>> rules, which is a [userspace-visible] bug. I'm not sure how far should
>> we go in bug compatibility.
>
> It is indeed the subsystem default (as m
>> - Thinking further on this, I realized that for common case signal
>> polarity is something defined by chip, and thus this knowledge belongs
>> to chip's driver and not to chip user's device tree. Moreover, device
>> tree writer could easily be not aware of signal polarity (too many
>> datasheet
> Hmm maybe yeah. I don't quite follow the above the "pinctrl-0 property
> of sx150x device tree node, is misinterpreted as hog" part though.
sx150x is i2c-gpio device. It has 16 GPIO lines that are communicated
with via i2c bus, and an interrupt line.
Interrupt line is typically connected to So
>>> Hmm maybe yeah. I don't quite follow the above the "pinctrl-0 property
>>> of sx150x device tree node, is misinterpreted as hog" part though.
>>
>> sx150x is i2c-gpio device. It has 16 GPIO lines that are communicated
>> with via i2c bus, and an interrupt line.
>>
>> Interrupt line is typicall
>>> Maybe create_pinctrl() could check if the pin controller device
>>> for a potential hog points to the device itself and bail out
>>> if that's not the case?
>>
>> Well that's exactly what patch from my first mail in this thread does.
>> This indeed fixes my case, but I don't know if it is corre
et to pinctrl device being registered. Need also check that
map's control device is also set to the same.
Signed-off-by: Nikita Yushchenko
---
drivers/pinctrl/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 1653
>> +/*
>> + * If pctldev is not null, we are claiming hog for it,
>> + * that means, setting that is served by pctldev by itself.
>> + *
>> + * Thus we must skip map that is for this device but is served
>> + * by other device.
Use SET_LATE_SYSTEM_SLEEP_PM_OPS() macro instead of direct assignment to
.resume_early field.
This fixes initialization of CS2000 in restore from hibernation in case
of kernel used to load image did not initialize CS2000 while kernel
being restored had CS2000 initialized.
Signed-off-by: Nikita
Use SET_SYSTEM_SLEEP_PM_OPS() macro instead of direct assignment to
.suspend and .resume fields.
This makes driver working after restore from hibernation.
Signed-off-by: Nikita Yushchenko
---
sound/soc/sh/rcar/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound
> + i2c_gpio: i2c-gpio {
> + compatible = "i2c-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_swi2c>;
> + i2c-gpio,delay-us = <50>;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-c
> There are three boards that share that configuration almost to a T,
> with the only difference is the particular GPIOs used. Putting it into
> a common file avoids repeating the boilerplate and makes it explicit
> to the reader that those settings are shared.
I'd agree if that boilerplate was 10
To fix that add a pinmux configuration line configureing the pad to
> function as a GPIO. While we are at it, add a corresponding
> output-high GPIO hog in an effort to minimize current consumption.
>
> Cc: Nikita Yushchenko
> Cc: Shawn Guo
> Cc: Fabio Estevam
> Cc: Lucas Stac
This adds rave-sp powerbutton and backlight devices to RDU1 device tree.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index
is the patch that was finally applied to the product (3.10
based).
commit 16cf72cfa72269b55fc5c878689e00c99b640d86
Author: Nikita Yushchenko
Date: Thu Apr 3 08:35:36 2014 +0400
powerpc: fix IRQ routing on Freescale boards with ULI1575 chip
Source: MontaVista Software, LLC
M
On RDU1, imx51 usbh1 interface is either not used, or used via external
block that breaks USB2 signalling.
To keep things working if high-speed device gets connected to that
block, use ChipIdea feature to limit port to full speed.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/imx51
Vybrid has single internal temperature sensor connected to both internal
ADC modules.
vf610-zii-dev already has ADC0 enabled. Now, to get temperature sensor
captured by iio_hwmon driver, need to configure iio_hwmon node to use
that ADC.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts
On RDU1, sdhc1 is used for eMMC, and that is 3.3V only.
Thus configure device node not to probe it as SD/SDIO and not try 1.8V.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
t' to use
values from memblock subsystem. These are adjusted at kernel memory
management init and thus always contain values that match reality.
Signed-off-by: Nikita Yushchenko
---
arch/powerpc/kernel/machine_kexec.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arc
Hi
While trying to make freescale p2020ds and mpc8572ds boards working with
mainline kernel, I faced that commit
e38c0a1f (Handle #address-cells > 2 specially) breaks things with these boards.
Both these boards have uli1575 chip.
Corresponding part in device tree is something like
Hi
While running LTP hugeltb tests on freescale powerpc board, I'm getting
[ 7253.637591] BUG: using smp_processor_id() in preemptible [ ]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not
> Could you try this?
>
> powerpc/hugetlb: replace __get_cpu_var with get_cpu_var
>
> Replace __get_cpu_var safely with get_cpu_var to avoid
> the following call trace:
Confirmed, no more acktraces.
Nikita
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
s.
Is there a sane way to handle hardware configurations like above in
device tree based kernel?
Nikita Yushchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
> On Thu, 2014-03-06 at 18:24 +0400, Nikita Yushchenko wrote:
> > When preparing dump-capturing kernel, kexec userspace tool needs to
> > know actual amount of memory used by the running kernel. This may
> > differ from extire available DRAM for a couple of reasons. To a
one board test passes and fsl-usb
init succeeds, but on other board test fails, causing fsl-usb init to
fail.
This patch changes ehci_fsl_setup_phy() not to test PHY_CLK_VALID on
controller version 1.6 that (per manual) does not have this bit.
Signed-off-by: Nikita Yushchenko
---
drivers/usb/host
Hmm... probably it was too early to apply this? I was just going
to prepare v2, based on discussion...
Which discussion?
One you are replying in?
https://lkml.org/lkml/2014/6/4/136
Also, applying only 11/21, without 01/21, will just cause build errors ...
CC'ing me on this patch alone w
With current 3.10.y, if kernel is booted with init=/bin/sh and then nfs mount
is attempted (without portmap or rpcbind running) using busybox mount, following
OOPS happen:
# mount -t nfs 10.30.130.21:/opt /mnt
svc: failed to register lockdv1 RPC service (errno 111).
lockd_up: makesock failed, erro
Hi.
Call Trace:
[e22d5a90] [c0007ea8] show_stack+0x4c/0x168 (unreliable)
[e22d5ad0] [c0618c04] __schedule_bug+0x94/0xb0
[e22d5ae0] [c060b9ec] __schedule+0x530/0x550
[e22d5bf0] [c060bacc] schedule+0x30/0xbc
[e22d5c00] [c060ca24] rt_spin_lock_slowlock+0x180/0x27c
[e22d5c70] [c00b39dc] res_counter_u
>> With current 3.10.y, if kernel is booted with init=/bin/sh and then nfs mount
>> is attempted (without portmap or rpcbind running) using busybox mount,
>> following
>> OOPS happen:
>>
>> # mount -t nfs 10.30.130.21:/opt /mnt
>> svc: failed to register lockdv1 RPC service (errno 111).
>> lockd_u
>> Currently many device tree aware drivers use irq_of_parse_and_map() to
>> get
>> IRQ number and then devm_request_irq() to set up IRQ handler.
>>
>> This causes a problem for exit path and for error paths: undo action for
>> irq_of_parse_and_map() is irq_dispose_mapping() that must not be called
oute IRQs via built-in i8259-compatible interrupt
controller.
Mention of "Disable INTx" in your code raises some ideas that perhaps
ULI *does* use INTx, and that could be somehow disabled...
Thanks in advance.
Nikita Yushchenko
RTsoft Sortware Development Center.
--
To unsubscribe from
should be
safe to disable preserving OHCI_FMINTERVAL if device vendor is ULI.
Signed-off-by: Nikita Yushchenko
---
drivers/usb/host/pci-quirks.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 00661d3
28.05.2014 03:27, Greg Kroah-Hartman пишет:
> On Tue, May 27, 2014 at 08:56:42AM +0400, Nikita Yushchenko wrote:
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
>>
>> Since preserving OHCI_FMINTERVAL was orig
27.05.2014 19:08, Alan Stern пишет:
> On Tue, 27 May 2014, Nikita Yushchenko wrote:
>
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
>
> Which access, the read or the write?
things are a bit more complex.
If ins
27.05.2014 20:39, Sergei Shtylyov пишет:
> Hello.
>
> On 05/27/2014 08:56 AM, Nikita Yushchenko wrote:
>
>> This access causes hang on Freescale P2020DS board (that has OHCI
>> provided by ULI 1533 chip).
>
>> Since preserving OHCI_FMINTERVAL was originally don
s
write routine, which results into OOPS dereferencing NULL chip->ecc.hwctl
pointer.
Signed-off-by: Nikita Yushchenko
---
drivers/mtd/nand/fsl_elbc_nand.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index ec549
> It would help to print the value of fminterval.
> And here to print the value obtained by the readl().
I've checked these... all values read as 0x - which does not
look correct
readl(base + OHCI_CONTROL) several lines before returns 0x
Read of HcRevision register (base + 0x0) at
>>> I think problem is caused by access to OHCI regs from PCI quirks - before
>>> driver was initialized. ULI1553 southbridge chip could be in strange state
>>> at this point.
>>
>> If that is the cause, we ought to be able to see it from the values
>> printed out by the debugging statements. And
29.05.2014 18:42, One Thousand Gnomes пишет:
>> I don't know how linux usb subsystem should behave against such
>> "half-existing" hardware. Perhaps hanging is not the best idea...
>> but maybe it should be fixed elsewhere, e.g. by masking non-wired
>> devices in platform PCI setup. Perhaps control
29.05.2014 19:33, Nikita Yushchenko пишет:
> 29.05.2014 18:42, One Thousand Gnomes пишет:
>>> I don't know how linux usb subsystem should behave against such
>>> "half-existing" hardware. Perhaps hanging is not the best idea...
>>> but maybe it should
29.05.2014 19:44, Alan Stern пишет:
> On Thu, 29 May 2014, Nikita Yushchenko wrote:
>
>> 29.05.2014 18:42, One Thousand Gnomes пишет:
>>>> I don't know how linux usb subsystem should behave against such
>>>> "half-existing" hardware. Perhap
>>> SPARC does not use OF_IRQ and has a different implementation of
>>> irq_of_parse_and_map than the one in drivers/of/irq.c. All code
>>> converted from irq_of_parse_and_map to devm_irq_of_parse_and_map in this
>>> patch set will be unlinkable for SPARC. This includes SPI in general and
>>> many
>> diff --git a/drivers/usb/host/ehci-grlib.c
>> b/drivers/usb/host/ehci-grlib.c
>> index 495b6fb..666c03e 100644
>> --- a/drivers/usb/host/ehci-grlib.c
>> +++ b/drivers/usb/host/ehci-grlib.c
>> @@ -111,11 +111,11 @@ static int ehci_hcd_grlib_probe(struct
>> platform_device *op)
>> hcd->rsrc_
17.06.2014 19:12, Lee Jones пишет:
From: Nikita Yushchenko
This avoids leak of IRQ mapping on error paths, and makes it possible
to use devm_request_irq() without facing unmap-while-handler-installed
issues.
Signed-off-by: Nikita Yushchenko
---
drivers/mfd/max8997.c |4 +++-
drivers
> Reverting would break Tegra PCIe, but you should not have to change the
> DT either. So we need a solution.
>
> Is this something like this sufficient to fix it?
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 4b9317b..378aebd 100644
> --- a/drivers/of/address.c
> +++ b/drive
reproduced.
Signed-off-by: Nikita Yushchenko
---
drivers/net/ethernet/freescale/gianfar.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
index 0343a14..9ac1946 100644
--- a/drivers/net
Hi
While working with board with imx6s cpu, with kernel based on linux-imx
imx_3.14.28_1.0.0_ga branch, I noticed this message in boot log:
> failed to set parent of clk gpu2d_core_sel to pll2_pfd1_594m
I looked into it and found that:
- CCM_CBCMR register layout is different between imx6q/imx
>> Not sure I understand logic behind this. With the current code,
>> resulting cpu_possible_mask depends on CONFIG_SMP_ON_UP:
>> - if it is set, cpu_possible_mask contains (0 1), as initialized in
>> arm_dt_init_cpu_maps()
>> - if it is not set, cpu_possible_mask contains (0), since
>> imx_smp_ini
28.11.2015 14:13, Nikita Yushchenko пишет:
>>> Not sure I understand logic behind this. With the current code,
>>> resulting cpu_possible_mask depends on CONFIG_SMP_ON_UP:
>>> - if it is set, cpu_possible_mask contains (0 1), as initialized in
>>> arm_dt_in
>> Just booted mainline... unline linux-imx, it does not try to init cpu1.
>>
>> However, imx6dl.dtsi from mainline also has both cpu@0 and cpu@1
>>
>> So missing piece in linux-imx is elsewhere :(
>
> It works as you mentioned - and it relies upon the code you tried to
> modify.
>
> The early b
> I'm still trying to understand what is going on, and my printk()s show
> that this is not entirely true.
>
> When smp_init() is entered on mainline om imx6s, cpu_possible_mask and
> cpu_present_mask both contain two cpus. These get initialized in
> arm_dt_init_cpu_maps() and stay unmodified sinc
24.11.2015 18:05, Nikita Yushchenko пишет:
>> I'm still trying to understand what is going on, and my printk()s show
>> that this is not entirely true.
>>
>> When smp_init() is entered on mainline om imx6s, cpu_possible_mask and
>> cpu_present_mask both contain
23.12.2014 08:36, Arseny Solokha пишет:
>> On Sat, 6 Dec 2014, Arseny Solokha wrote:
>>
>>> From: Arseny Solokha
>>>
>>> Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
>>> introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
>>> board. The code path that was
appened to this effort :(
What is the latest status of "idle time bkops" functionality?
Is any working implementation available?
TIA,
Nikita Yushchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
]
>>
>> [1] https://lkml.org/lkml/2013/4/14/29
>>
>> However this did not land in mainline, also no replies, and no sign of
>> any follow-up... Complete mystery what has happened to this effort :(
>>
>> What is the latest status of "idle time bkops&quo
Hi
arch/powerpc/sysdev/fsl_lbc.c driver claims that it is compatible with
fsl,pq2-localbus and fsl,pq2pro-localbus
arch/powerpc/sysdev/fsl_lbc.c driver requires irq configured in device
tree since very old times (commit 3ab8f2a2 from 2.6.37 times)
None of in-tree dts files that have either fsl,p
Hi
>> While working with board with imx6s cpu, with kernel based on linux-imx
>> imx_3.14.28_1.0.0_ga branch, I noticed this message in boot log:
>>
>>> failed to set parent of clk gpu2d_core_sel to pll2_pfd1_594m
>>
>>
>> I looked into it and found that:
>>
>> - CCM_CBCMR register layout is diffe
23.11.2015 15:03, Russell King - ARM Linux пишет:
> On Mon, Nov 23, 2015 at 02:59:06PM +0300, nyushche...@dev.rtsoft.ru wrote:
>> From: Nikita Yushchenko
>>
>> While running an imx6s boasrd, I got following message in boot log:
>>
>> [0.032414] CPU1: fail
While running an imx6s boasrd, I got following message in boot log:
[0.032414] CPU1: failed to boot: -38
This looked strange: imx6s is singe-core and kernel perfectly knows
that. However, for some reason it tries to initialize CPU 1?
I found this to be ca
23.11.2015 15:19, Russell King - ARM Linux пишет:
> On Mon, Nov 23, 2015 at 12:12:16PM +, Russell King - ARM Linux wrote:
>> iMX6 is fairly well supported in mainline. The only reason to use a
>> custom kernel is if you want to use some feature which mainline does
>> not support (or support ve
> While running an imx6s boasrd, I got following message in boot log:
>
> [0.032414] CPU1: failed to boot: -38
>
> This looked strange: imx6s is singe-core and kernel perfectly knows
> that. However, for some reason it tries to initialize CPU 1?
>
> I found this
IRQ storm: unmasked Rx interrupt happens again
and again is misprocessed in the same way.
This patch fixes that scenario by unmasking Rx interrupts only when
napi_complete_done() returns true, which means it has cleared
NAPIF_STATE_SCHED in state.
Signed-off-by: Nikita Yushchenko
---
drivers
This fixes errors in RDU1 device tree that cause touch screens not
working.
Signed-off-by: Nikita Yushchenko
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
b/arch/arm/boot/dts/imx51-zii
;
> Aieee I was typing too fast today, sorry...
>
> send separate "fix for the fix", or re-send patch without that silly typo?
>
> Nikita
>
>> Hi Nikita,
>>
>> [auto build test ERROR on net/master]
>>
>> url:
>> https://github
Aieee I was typing too fast today, sorry...
send separate "fix for the fix", or re-send patch without that silly typo?
Nikita
> Hi Nikita,
>
> [auto build test ERROR on net/master]
>
> url:
> https://github.com/0day-ci/linux/commits/Nikita-Yushche
> From: Nikita Yushchenko
> Date: Mon, 5 Dec 2016 16:55:04 +0300
>
>> Aieee I was typing too fast today, sorry...
>>
>> send separate "fix for the fix", or re-send patch without that silly typo?
>
> If the patch hasn't been applied yet, you re
andling of !defined(CONFIG_M5272) case.
Fixes: 4dfb80d18d05 ("net: fec: cache statistics while device is down")
Signed-off-by: Nikita Yushchenko
---
Changes since v2:
- fix typo that caused compile problem, double-check that it compiles
and works as expected.
drivers/net/ethernet/frees
> +#define FEC_STATS_SIZE (ARRAY_SIZE(fec_stats) * sizeof(u64))
>
>
> Do I take it right this actually translates to (sizeof(fec_stats) /
> sizeof(u64) * sizeof(u64))?
No.
fec_stats is an array of structs, each struct has car arrsy and integer,
and size of that is definitely not byt
andling of !defined(CONFIG_M5272) case.
Fixes: 80cca775cdc4 ("net: fec: cache statistics while device is down")
Signed-off-by: Nikita Yushchenko
---
Changes from v3:
- fix reference commit id to match upstream tree
drivers/net/ethernet/freescale/fec_main.c | 13 ++---
1 file ch
>>> Just a guess, but if the inbound translation windows in the host
>>> bridge are wider than 32-bit, the reason for setting up a single
>>> 32-bit window is probably because that is what the parent bus supports.
I've re-checked rcar-pcie hardware documentation.
It indeed mentions that AXI bus i
and dev->dma_coherent_mask must still keep values
that hardware handles physically.
This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.
Signed-off-by: Nikita Yushchenko
CC: Arnd Bergmann
---
arch/arm64/Kconfig | 3 +++
and dev->dma_coherent_mask must still keep values
that hardware handles physically.
This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.
Signed-off-by: Nikita Yushchenko
CC: Arnd Bergmann
---
... now with initially missed change in arch_se
>> There is a use cases when architecture is 64-bit but hardware supports
>> only DMA to lower 4G of address space. E.g. NVMe device on RCar PCIe host.
>>
>> For such cases, it looks proper to call blk_queue_bounce_limit() with
>> mask set to 0x - thus making block layer to use bounce buff
>> +if (mask > dev->archdata.parent_dma_mask)
>> +mask = dev->archdata.parent_dma_mask;
>> +
>> +
>
>One empty line is enough...
Ok
>> +/*
>> + * Whatever the parent bus can set. A device must not set
>> + * a DMA mask larger than this.
>> + */
>> +dev->archda
and dev->dma_coherent_mask must still keep values
that hardware handles physically.
This patch enforces that. Based on original version by
Arnd Bergmann , extended with coherent mask hadnling.
Signed-off-by: Nikita Yushchenko
CC: Arnd Bergmann
---
Changes since v1:
- fixed issues noted by Serg
>>> I run into same issue and posted a patch:
>>
>>> "ASoC: Fix binding and probing of auxiliary components".
>>
>> Which I applied so I guess things are fine now without the revert? I'm
>> still working through backlog from the holidays so didn't check
>> properly yet.
>
> This fixes the Allwinn
[CCing NVMe maintainers since we are discussion issues in that driver]
>> With my patch applied and thus 32bit dma_mask set for NVMe device, I do
>> see high addresses passed to dma_map_*() routines and handled by
>> swiotlb. Thus your statement that behavior "succeed 64bit dma_set_mask()
>> opera
Hi
There is a use cases when architecture is 64-bit but hardware supports
only DMA to lower 4G of address space. E.g. NVMe device on RCar PCIe host.
For such cases, it looks proper to call blk_queue_bounce_limit() with
mask set to 0x - thus making block layer to use bounce buffers
for any
>> I believe the bounce buffering code you refer to is not in SATA/SCSI/MMC
>> but in block layer, in particular it should be controlled by
>> blk_queue_bounce_limit(). [Yes there is CONFIG_MMC_BLOCK_BOUNCE but it
>> is something completely different, namely it is for request merging for
>> hw not
eeded here.
Nikita
> On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote:
>> I'm now working with HW that:
>> - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores,
>> and is being manufactured and developed,
>>
Hi
> The point here is that an IOMMU doesn't solve your issue, and the
> IOMMU-backed DMA ops need the same treatment. In light of that, it really
> feels to me like the DMA masks should be restricted in of_dma_configure
> so that the parent mask is taken into account there, rather than hook
> int
>> What issue "IOMMU doesn't solve"?
>>
>> Issue I'm trying to address is - inconsistency within swiotlb
>> dma_map_ops, where (1) any wide mask is silently accepted, but (2) then
>> mask is used to decide if bounce buffers are needed or not. This
>> inconsistency causes NVMe+R-Car cobmo not workin
And in this case, change done by that commit
jumps directly to queue_work().
However, work routine pn533_wq_cmd_complete() unconditionally calls
pn533_send_async_complete(), and that unconditionally dereferences
dev->cmd. Thus crash.
Not yet sure how to fix that properly...
WBR,
Nikita Yushchenko
>> Hmm... I'm not about device writing to memory.
>
> This absolutely is about whether the device wrote into the
> area or not.
Not only.
>> Sequence in igb driver is:
>>
>> dma_map(full_page)
>>
>> sync_to_cpu(half_page);
>> skb_add_rx_frag(skb, half_page);
>> napi_gro_receive(skb);
>> .
>> All the data has been synced
>
> Non-synced data is write done by CPU executing upper layers of network stack,
Upper layers shall never get area that is still dma_map()ed and will be
dma_unmap()ed in future. But with igb, this is exactly what happens.
1 - 100 of 198 matches
Mail list logo
