<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers, branch v2024.01-rc3</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>scsi: set dma direction to NONE for TEST UNIT READY</title>
<updated>2023-11-20T13:34:08+00:00</updated>
<author>
<name>Nikita Yushchenko</name>
<email>nikita.yoush@cogentembedded.com</email>
</author>
<published>2023-11-13T05:51:02+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=beeb91aa64fde9e35ccfacf03b3d0323b4bf7329'/>
<id>beeb91aa64fde9e35ccfacf03b3d0323b4bf7329</id>
<content type='text'>
SCSI device scan code was executing TEST UNIT READY command without
explicitly setting dma direction in struct scsi_cmd to NONE, so command
was passed to driver with dma direction set to DMA_FROM_DEVICE,
inherited from older usage.

With WDC SDINDDH6-64G ufs device, that caused TEST UNIT READY to
return error.

Fix that, by explicitly setting dma direction to NONE for
TEST UNIT READY, and restoring it back DMA_FROM_DEVICE for the
following READ CAPACITY.

Signed-off-by: Nikita Yushchenko &lt;nikita.yoush@cogentembedded.com&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SCSI device scan code was executing TEST UNIT READY command without
explicitly setting dma direction in struct scsi_cmd to NONE, so command
was passed to driver with dma direction set to DMA_FROM_DEVICE,
inherited from older usage.

With WDC SDINDDH6-64G ufs device, that caused TEST UNIT READY to
return error.

Fix that, by explicitly setting dma direction to NONE for
TEST UNIT READY, and restoring it back DMA_FROM_DEVICE for the
following READ CAPACITY.

Signed-off-by: Nikita Yushchenko &lt;nikita.yoush@cogentembedded.com&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'master-mmc-clock' of https://source.denx.de/u-boot/custodians/u-boot-sh</title>
<updated>2023-11-18T15:25:48+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2023-11-18T15:25:48+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d5ff806cb57359ac5084e2af6a96463c9da772ba'/>
<id>d5ff806cb57359ac5084e2af6a96463c9da772ba</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio: rng: gracefully handle 0 byte returns</title>
<updated>2023-11-17T16:58:26+00:00</updated>
<author>
<name>Andre Przywara</name>
<email>andre.przywara@arm.com</email>
</author>
<published>2023-11-07T16:09:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=45c4b276f0a4d67e06c94de3d0a5dadf4bee530a'/>
<id>45c4b276f0a4d67e06c94de3d0a5dadf4bee530a</id>
<content type='text'>
According to the virtio v1.x "entropy device" specification, a virtio-rng
device is supposed to always return at least one byte of entropy.
However the virtio v0.9 spec does not mention such a requirement.

The Arm Fixed Virtual Platform (FVP) implementation of virtio-rng always
returns 8 bytes less of entropy than requested. If 8 bytes or less are
requested, it will return 0 bytes.
This behaviour makes U-Boot's virtio_rng_read() implementation go into an
endless loop, hanging the system.

Work around this problem by always requesting 8 bytes more than needed,
but only if a previous call to virtqueue_get_buf() returned 0 bytes.

This should never trigger on a v1.x spec compliant implementation, but
fixes the hang on the Arm FVP.

Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Reported-by: Peter Hoyes &lt;peter.hoyes@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
According to the virtio v1.x "entropy device" specification, a virtio-rng
device is supposed to always return at least one byte of entropy.
However the virtio v0.9 spec does not mention such a requirement.

The Arm Fixed Virtual Platform (FVP) implementation of virtio-rng always
returns 8 bytes less of entropy than requested. If 8 bytes or less are
requested, it will return 0 bytes.
This behaviour makes U-Boot's virtio_rng_read() implementation go into an
endless loop, hanging the system.

Work around this problem by always requesting 8 bytes more than needed,
but only if a previous call to virtqueue_get_buf() returned 0 bytes.

This should never trigger on a v1.x spec compliant implementation, but
fixes the hang on the Arm FVP.

Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Reported-by: Peter Hoyes &lt;peter.hoyes@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dm: Do not enable debug messages by default</title>
<updated>2023-11-15T03:04:01+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2023-11-04T18:40:43+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2c61c0eb14289cbd94bff51c175f2410418d64d0'/>
<id>2c61c0eb14289cbd94bff51c175f2410418d64d0</id>
<content type='text'>
CONFIG_DM_WARN has a text indicating that these messages should only
provided when debugging. This implies that the setting must be default no.

We should still create debug messages.

Reported-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CONFIG_DM_WARN has a text indicating that these messages should only
provided when debugging. This implies that the setting must be default no.

We should still create debug messages.

Reported-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: renesas-sdhi: Disable clock after tuning reset when possible</title>
<updated>2023-11-13T03:12:47+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marek.vasut+renesas@mailbox.org</email>
</author>
<published>2023-11-05T22:42:45+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=70d2c9940e54ada6bf9e1e538c958f13ccc97c38'/>
<id>70d2c9940e54ada6bf9e1e538c958f13ccc97c38</id>
<content type='text'>
Currently the renesas_sdhi_reset_tuning() unconditionally leaves SDHI
clock enabled after the tuning reset. This is not always necessary.

After the driver performed tuning reset at the end of probe function,
or in the unlikely case that tuning failed during regular operation,
the SDHI clock can be disabled after the tuning reset. The following
set_ios call would reconfigure the clock as needed.

In case of regular set_ios call which requires a tuning reset, keep
the clock enabled or disabled according to the mmc-&gt;clk_disable state.

With this in place, the controllers which have not been accessed via
block subsystem after boot are left in quiescent state. However, if an
MMC device is used e.g. for environment storage, that controller would
be accessed during the environment load and left active, including its
clock which would still be generated. This is due to the design of the
MMC subsystem, which does not deinit a controller after it was started
once, the controller is only deinited in case of mmc rescan, or before
OS boot.

Signed-off-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Paul Barker &lt;paul.barker.ct@bp.renesas.com&gt;
Tested-by: Paul Barker &lt;paul.barker.ct@bp.renesas.com&gt;
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Thuan Nguyen Hong &lt;thuan.nguyen-hong@banvien.com.vn&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the renesas_sdhi_reset_tuning() unconditionally leaves SDHI
clock enabled after the tuning reset. This is not always necessary.

After the driver performed tuning reset at the end of probe function,
or in the unlikely case that tuning failed during regular operation,
the SDHI clock can be disabled after the tuning reset. The following
set_ios call would reconfigure the clock as needed.

In case of regular set_ios call which requires a tuning reset, keep
the clock enabled or disabled according to the mmc-&gt;clk_disable state.

With this in place, the controllers which have not been accessed via
block subsystem after boot are left in quiescent state. However, if an
MMC device is used e.g. for environment storage, that controller would
be accessed during the environment load and left active, including its
clock which would still be generated. This is due to the design of the
MMC subsystem, which does not deinit a controller after it was started
once, the controller is only deinited in case of mmc rescan, or before
OS boot.

Signed-off-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Paul Barker &lt;paul.barker.ct@bp.renesas.com&gt;
Tested-by: Paul Barker &lt;paul.barker.ct@bp.renesas.com&gt;
Reviewed-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Tested-by: Thuan Nguyen Hong &lt;thuan.nguyen-hong@banvien.com.vn&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>power: regulator: add AXP313 support</title>
<updated>2023-11-12T16:47:16+00:00</updated>
<author>
<name>Andre Przywara</name>
<email>andre.przywara@arm.com</email>
</author>
<published>2023-10-17T13:12:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=fafedff35015c8cca7c537b68deb57b22c3ead73'/>
<id>fafedff35015c8cca7c537b68deb57b22c3ead73</id>
<content type='text'>
The X-Powers AXP313a is a small PMIC with just three buck converters and
three LDOs, one of which is actually fixed (so not modelled here).

Add the compatible string and the respective regulator ranges to allow
drivers to adjust voltages.

Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The X-Powers AXP313a is a small PMIC with just three buck converters and
three LDOs, one of which is actually fixed (so not modelled here).

Add the compatible string and the respective regulator ranges to allow
drivers to adjust voltages.

Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>power: pmic: sunxi: add AXP313 SPL driver</title>
<updated>2023-11-12T16:47:16+00:00</updated>
<author>
<name>Andre Przywara</name>
<email>andre.przywara@arm.com</email>
</author>
<published>2023-07-30T00:11:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d17d051c540a97b8d0b38236dd7fef2294db4e48'/>
<id>d17d051c540a97b8d0b38236dd7fef2294db4e48</id>
<content type='text'>
On boards using the AXP313 PMIC, the DRAM rail is often not setup
correctly at reset time, so we have to program the PMIC very early in
the SPL, before running the DRAM initialisation.

Add a simple AXP313 PMIC driver that knows about DCDC2(CPU) and
DCDC3(DRAM), so that we can bump up the voltage before the DRAM init.

Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Acked-by: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On boards using the AXP313 PMIC, the DRAM rail is often not setup
correctly at reset time, so we have to program the PMIC very early in
the SPL, before running the DRAM initialisation.

Add a simple AXP313 PMIC driver that knows about DCDC2(CPU) and
DCDC3(DRAM), so that we can bump up the voltage before the DRAM init.

Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Acked-by: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pinctrl: sunxi: Avoid using .bss for SPL</title>
<updated>2023-11-12T16:46:46+00:00</updated>
<author>
<name>Samuel Holland</name>
<email>samuel@sholland.org</email>
</author>
<published>2023-10-31T04:57:40+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0070d57c339061e4725909b3081d70b83c2132d1'/>
<id>0070d57c339061e4725909b3081d70b83c2132d1</id>
<content type='text'>
sunxi platforms put .bss in DRAM, so .bss is not available in SPL before
DRAM controller initialization. Therefore, this buffer must be placed in
the .data section.

Signed-off-by: Samuel Holland &lt;samuel@sholland.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
sunxi platforms put .bss in DRAM, so .bss is not available in SPL before
DRAM controller initialization. Therefore, this buffer must be placed in
the .data section.

Signed-off-by: Samuel Holland &lt;samuel@sholland.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sunxi: mmc: Sort compatible strings numerically</title>
<updated>2023-11-12T16:46:32+00:00</updated>
<author>
<name>Samuel Holland</name>
<email>samuel@sholland.org</email>
</author>
<published>2023-10-31T05:22:34+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d379bcbfafc7162c145946bb907bb4a935a0bbd9'/>
<id>d379bcbfafc7162c145946bb907bb4a935a0bbd9</id>
<content type='text'>
commit 95168d77d391 ("sunxi: add Allwinner R528/T113 SoC support") added
the new entry out of order.

Signed-off-by: Samuel Holland &lt;samuel@sholland.org&gt;
Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 95168d77d391 ("sunxi: add Allwinner R528/T113 SoC support") added
the new entry out of order.

Signed-off-by: Samuel Holland &lt;samuel@sholland.org&gt;
Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>clk: sunxi: Use the right symbol in the Makefile</title>
<updated>2023-11-12T16:46:16+00:00</updated>
<author>
<name>Samuel Holland</name>
<email>samuel@sholland.org</email>
</author>
<published>2023-10-31T04:49:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ca43266562461c3bd871da5adffecc46eb05dc56'/>
<id>ca43266562461c3bd871da5adffecc46eb05dc56</id>
<content type='text'>
CONFIG_ARCH_SUNXI will not be enabled for RISC-V SoCs using this driver.
Use the symbol for the driver itself instead.

Signed-off-by: Samuel Holland &lt;samuel@sholland.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CONFIG_ARCH_SUNXI will not be enabled for RISC-V SoCs using this driver.
Use the symbol for the driver itself instead.

Signed-off-by: Samuel Holland &lt;samuel@sholland.org&gt;
Reviewed-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
