These fields are defined by FAT32 itself, and are specified as 32-bit
values. So switch them from sector_t to simple uint32_t.
Change-Id: I98afecfbe1f8a1b83fbdd4ec3fea016b8e0b985d
According to the datasheet, the PLL fractional mode is
apparently not supported in the medium VCO range.
The LCD isn't picky about front/back porch settings so
modify these to get a dot clock close to 6 MHz (within
~0.1% error).
Change-Id: I51647534db8c2b261391864db9262a0b04548e6d
* pcm_play_data
* pcm_play_stop
* pcm_play_stop_int
* pcm_is_playing
* pcm_set_frequency
* pcm_get_frequency
* pcm_apply_settings
Now, the only user of these functions are the mixer and recording layers
that provide a higher-level API to plugins and the main [playback]
application.
Outside of the PCM core, pcm_apply_settings() was only used immediately
following a call to mixer_set_frequency(), so the latter function
now always calls the former.
Change-Id: I61c3144dc156b9de9b7963160b525c6d10c6ad4b
Playback is implemented using a target-specific PCM layer,
using the STM32H7 SAI & DMA registers directly. There are
a number of pop/click issues:
1. Slight click when powering up the amplifiers
2. Click when starting and stopping playback
3. Popping when changing playback frequency
4. Popping when shutting down
It should be possible to eliminate or at least mitigate
(2) to (4) in software, but (1) happens as a result of
powering on the amplifiers while everything is muted so
might be unavoidable.
Change-Id: I398b66596176fb2341beb7deba7bf6f4f3fb82b3
move target-specific pcm operations into builtin_pcm_sink.
in subsequent commits, another pcm_sink is added, and it becomes
possible to switch between them.
Change-Id: I8f8b9661e01d6e6472f34224ddc3760856778457
Though the rev1 hardware is capable of recording from a
headset mic, this feature seems likely to be dropped on
future hardware revisions, and I don't see much point to
implementing it now.
Change-Id: I77e403bdd1ca53f9018835d3c3042dc86ee0f8f3
Remove the generic TLV320AIC3104 codec header. The codec
is sufficiently complex that a one-size-fits-all driver
isn't really feasible, eg. due to different clocking and
output configurations.
It's easier for targets to have their own audio headers
tailored to their use case than a generic header with
lots of ifdefs.
Change-Id: I63d92d57c28ddd7da7aa3174bd583d8afb1aa56d
Firmware didn't start sleep countdown if
1. Display was already dimmed
2. Fade out timer was set
You can reproduce this by:
1. Set fade out timer. For example, 500ms
2. Wait till display will be dimmed and go to sleep
3. Switch hold ON or plug headphones
Change-Id: I27ca857aa8db4551bd9caad4815cd73a64bf6185
According to RM0433 the DCTRL register needs to be written
after DLENR and DTIMER. This is respected for data transfer
commands but not for non-data commands. Nothing bad seems
to be happening because of this, but it seems wise to rectify
the issue.
Change-Id: I55d8f2c1994bff747e5978847fda57445f001b02
According to RM0433 consecutive writes to the CLKCR and CMDR
registers must be separated by at least 7 AHB clock cycles.
The initialization code didn't respect this and it seemed to
be causing a nasty bug, where the SDMMC bus clock got stuck
at 400 KHz in hardware. Despite the CLKCR register reading
back the correct value, it could not be written with a new
value even in the debugger; resetting the peripheral was the
only way out of this state.
Adding some dummy register reads after any access to CLKCR
should insert the necessary number of wait states. Without
the fix, the SDMMC clock gets stuck about 12% of the time.
With this fix, the clock always initializes correctly.
Change-Id: Iba85b8e1e3c60992ddc42fb4c1e66c37941ed617
If not, these devices will charge very slowly (0.07A) when plugged into a wall plug, and will all discharge slowly when docked & playing music.
Enabling this option (that is already enabled by default on some other devices like erosq and fiio m3k) make them pull between 0.20 and 0.30. They charge faster, just as fast as on Stock OS, and won't discharge when playing music while docked.
Change-Id: I90a59caaca463354772b1869f7333d8efce4f117
Replace the factor calculation from pcm-alsa.c, which
is based on signal *power* ratios, with the fp_factor()
calculation that is based on amplitude ratios. Because
power changes with the square of amplitude, this means
1 dB of power equals 2 dB of amplitude.
Rockbox's volume controls are amplitude-based, so the
smallest step size for pcm-alsa was effectively 2 dB.
The fp_factor() method supports 0.1 dB steps and is a
bit more accurate besides, so it's simply superior in
all respects (aside from taking a few more CPU cycles
to calculate the factor).
Change-Id: I34d143c225d8b5e085cde299fc405f83c13314bf
Disabling an IRQ in the NVIC may not take effect right away;
if the IRQ is being disabled to implement a critical section
it's necessary to follow up with dsb + isb to serialize the
NVIC update. Add a helper function for doing this.
Change-Id: Iaaa238ad39997cc3c6d62867d265cf9e9e0e5c4b
pcm_play_data -> mixer_channel_play_data
pcm_set_frequeny -> mixer_set_frequency
pcm_play_stop -> audio_stop at startup / mixer_channel_stop at shutdown
pcm_is_playing -> mixer_channel_status
All of these have been removed from the plugin API. Updated API docs to
clarify role of audio_stop() vs mixer_channel_stop()
Todo: get rid of pcm_play_[un]lock().
Change-Id: I8800c131b51f064ee923a4c6e42aa405d33851fc
At low speed there's some occasional corrupted pixels,
most visible on album art and such; this goes away at
medium speed.
Change-Id: Ice4eaec4284023d2d3f5c571b242cb27ebc26da9
The problem with drive strength and things not working reliably
at 50 MHz turned out to be entirely caused by the ESD diodes on
the data/command/clock lines, which have a whopping 200-300 pF
junction capacitance -- 6-10x higher than the 30 pF limit given
by the MMC spec.
After desoldering the diodes the bus seems stable at 50 MHz and
with any drive strength (note MEDIUM is still fast enough even
for 50 MHz, so the drive strength is unchanged).
Change-Id: If9847ee4145f5ed2f7e172cfa89acad0737a897f
* Get rid of the SD_CIM_RESET meta-command and put all
reset/init logic into one place
* Don't double-issue the SD_GO_IDLE_STATE command
* Explicitly set lowest speed upon reset
Change-Id: I5abfe9f64997e39087b8a77d525f90c77733a1a8
It was limited to 48KHz due to insufficient IRAM but at some point in
the last five years or so that must have changed.
Change-Id: Ia893ed5e1f3026158daad77991c3d9cca2fed97c
* Rework logf/DEBUG distinction
* Don't try to init a card that isn't detected
* Inform card that host supports SDUC
* Implement CMD22 (SET_UPPER_ADDR)
* Implement CMD23 (SET_BLOCK_COUNT)
* Disable DMA for transfers under 512 bytes
* Created ACMD+data xfer command path
* Incorrect handling of RESPONSE_R7
* Clean up 4bit stuff, only turn it on after we enable it in the card.
* Clear END_CMD_RES bit _after_ we check the status
* Probe SCR <-- NOT YET WORKING, DISABLED
jz4740 had these additional improvements:
* Restructuring to bring it closer to 4760 driver
* Unified read/write setup code
* IRQ handling and polling improvements
Change-Id: I47379f097af4bf50177499b3d80a6c9c42d48057
Low speed works for 50pF loads up to 12 MHz. LCD signals
fall well within those limits so there's no reason to use
any higher speed.
Change-Id: I6dab899fac316bb02572174ef13a98cccbf4ae66
The semaphore was released after all bytes were read/written
without waiting for the EOT event, which is why the delay at
the end of the transfer needed to be longer than expected.
Change-Id: I6b48fc01cda69564c0ec8f843afd1b0c3a9c5a3c
I have a 1TB SD card that gets filesystem corruption when writing large
amounts of data when using Rockbox in USB storage mode. The card doesn't show
this behaviour when using the original firmware or when using an external SD
card writer.
This is on an Aigo Eros Q device. Same brand 512GB card does not exhibit this
behaviour.
Whether this specific SD card explicitly requires CMD23 or if there's a
problem with the controller's timing of auto-CMD12 in combination with this
card is currently unknown, but implementing it does solve the problem.
This change request implements CMD23 by first probing if SBC is supported by
the SD card and then using it instead of AUTO_CMD12.
Change-Id: Ib2dc8e179b0fab98ca59c348061cb7d5850884dd
The driver didn't handle the busy signal at the end of
some command responses (R1b response type), notably the
CMD12 (STOP_TRANSMISSION) sent after a multiblock write
would time out because DTIMER==0 and leave the DPSM in
an incorrect state for the next command, causing a hang.
Change-Id: I406337a7612f759418a4872979aa2de5aa2244c7
When doing I/O, the interrupt can rarely fire with no
active command and no status bits set. This is probably
because the interrupt is set pending by the NVIC while
the handler is already running, so should be harmless.
Change-Id: I0c2570abe6e3c85ddbfa2ebe0afcf8677b77408f
I'm leaving it enabled because that's clearly the intent
of the bootloader, but at least there's now an easy path to disabling it
if so desired.
Change-Id: I4f4ecc9a453d376f92e411e0544b587fe4b4c864
This way we don't need to stub out a bunch of functionality when we
don't have any actual USB class drivers enabled.
Change-Id: Ia0ecf5be4bb41bebfcd347090959f3204a2aba59
They haven't seen development activity for the better part
of two decades and apparently were never able to even boot
to Rockbox, although the Rockbox bootloader could load the
original firmware.
Change-Id: I5cfa5909c21feaf2825aa685a05e78044b893a13
Allow toggling the system debug state from the debug menu
in Rockbox, or by holding a button combo at boot, so that
an SWD/JTAG debugger can be attached to normal non-debug
builds without too much hassle.
Change-Id: Iee47ef916ade2e5ec1094a63c68e48f1b27b0bbb
While 50 MHz works for low activity and small amounts of
data, there are frequent CRC errors when handling larger
transfers. Increasing drive strength only makes it worse.
Everything seems stable at 25 MHz though.
Change-Id: I3471c490ab63b2302b21ee2fe601519ee5a40ce5
