On Wed, Oct 28, 2020 at 10:39:12AM +0100, Matthias Reichl wrote:
On Wed, Oct 28, 2020 at 01:18:33AM -0700, Allen Martin wrote:
Hi, just checking if you had a chance to review this patch.
On Sat, Oct 10, 2020 at 12:26 PM Allen Martin wrote:
> Add functions to control enable/disable of B
in the FIFO. The max98357 dac makes a
loud popping sound when BCLK is toggling but LRCLK is not.
Signed-off-by: Allen Martin
---
sound/soc/bcm/bcm2835-i2s.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm
max_instr: 12
min_instr: 9
avg_instr: 10
min_time: 64ns
max_time: 224ns
avg_time: 64ns
cpu: 3
max_instr: 44
min_instr: 9
avg_instr: 11
min_time: 64ns
max_time: 160ns
avg_time: 64ns
Signed-off-by: Allen Martin
---
include/linux/sched.h | 4
kernel/sched/core.c | 4
kernel/sched/fair.c
Add atomic.h to provide atomic_long_t used in struct shrinker
Signed-off-by: Allen Martin
---
include/linux/shrinker.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 4fcacd915d45..02ec84b22f4b 100644
--- a/include/linux/shrinker.h
Fix name of slink binding and address of sflash example to make it
self consistent.
Change-Id: Ia89c3017c958bdf670036caf516eabce6f893096
Signed-off-by: Allen Martin
---
Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt |2 +-
Documentation/devicetree/bindings/spi/nvidia
> > Dunno about the NVidia version.
>
> Theirs works rather differently - the GO bit is there, but there's
> another append register which is used to tell the controller
> that a new
> tag has been added to the CPB list.
>
> The only thing we currently use the GO bit for is to switch
> betw
> The software definitely provides that guarantee for all NCQ-capable
> controllers.
>
Well if that's not it, it must be some problem entering ADMA legacy
mode. Here's what the Windows driver does:
ADMACtrl.aGO = 0
ADMACtrl.aEIEN = 0
poll {
until ADMAStatus.aLGCY = 1 || timeout
}
--
> The question I had for NVIDIA regarding this that I never got
> answered
> was, is there any reason why we would need a delay when switching
> between NCQ and non-NCQ commands on ADMA, and if not, is
> there any known
> cause that could cause the controller to get into this seemingly
> loc
> Alan Cox wrote:
> > On Wed, 12 Dec 2007 21:58:25 +0100
> > Rene Herman <[EMAIL PROTECTED]> wrote:
> >
> >> On 12-12-07 21:26, Rene Herman wrote:
> >>
> >>> On 12-12-07 21:07, David P. Reed wrote:
> Someone might have an in to nVidia to clarify this,
> since I don't.
> In any case, t
> > What I'm worred about is SMI traps implemented in the SBIOS for AHCI
> > workarounds that may be disabled when in IDE mode.
>
> For Nvidia devices those would only be present if there were problems
> with the AHCI hardware right, which would mean you could
> simply tell us
> what workarounds
> Allen Martin wrote:
> > At least for NVIDIA controllers, loading the AHCI driver
> when the BIOS
> > is set to IDE mode is not recommended by NVIDIA. Any AHCI
> workarounds
> > in the BIOS are likely to be disabled when set to IDE mode.
> In practice
>
> Alan Cox wrote:
> > On Thu, 8 Nov 2007 22:46:22 -0500
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
> >>> And I might even privately patch my own kernels to map
> the ACHI BAR
> >>> in the cases where the BIOS didn't...
> >> The
> Couldn't be do this generically inside libata core somehow,
> i.e. try to
> use ACPI to set the proper mode and fall back to the driver-specific
> mode setting code if that didn't work? I think if we could do that it
> would solve a number of problems (i.e. we could prevent it from doing
> t
Windows, so you know it's received a
lot of testing from NVIDIA and board vendors.
-Allen
> -Original Message-
> From: Bartlomiej Zolnierkiewicz [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 05, 2007 7:09 AM
> To: Allen Martin
> Subject: Fwd: Nvidia cable detecti
> I'd like to here from Andi how he feels about this? It seems like a
> somewhat drastic solution in some ways given a lot of hardware doesn't
> seem to be affected (or maybe in those cases it's just really hard to
> hit, I don't know).
>
> > Well we can hope that Nvidia will find out more (thoug
> > static irqreturn_t nv_adma_interrupt(int irq, void *dev_instance)
> > {
> > struct ata_host *host = dev_instance;
> > int i, handled = 0;
> > + u32 notifier_clears[2];
> >
> > spin_lock(&host->lock);
> >
> > for (i = 0; i < host->n_ports; i++) {
> > struct at
> Erm, why they are not willing to support NCQ under Linux...I
> mean many
> people using NVIDIA based mainboards. And that against that what I
> thought NVidia stands for - Linux friendly but seems only that this
> statement fit on graficcards? Is there no "responsible" person that
> says...H
> > Ask NVIDIA. They are the only company that gives me -zero-
> > information on their SATA controllers.
>
> I thought of that.. *sigh*
NVIDIA won't be documenting nForce4 SATA controllers, so Linux NCQ
support for nForce4 is unlikely. I'm hoping this will change with
future products.
> > A
18 matches
Mail list logo
