* [PATCH v2 for-4.14] tools/libxl: fix setting altp2m param broken by 1e9bc407cf0
From: Tamas K Lengyel @ 2020-05-29 16:22 UTC (permalink / raw)
To: xen-devel
Cc: Anthony PERARD, Andrew Cooper, Tamas K Lengyel, Ian Jackson,
Wei Liu
The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
boolean. This is incorrect and breaks external-only usecases of altp2m that
is set with a value of 2.
Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
---
v2: just convert bool to unsigned int
---
tools/libxl/libxl_x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index f8bc828e62..e57f63282e 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -391,7 +391,7 @@ static int hvm_set_conf_params(libxl__gc *gc, uint32_t domid,
libxl_ctx *ctx = libxl__gc_owner(gc);
xc_interface *xch = ctx->xch;
int ret = ERROR_FAIL;
- bool altp2m = info->altp2m;
+ unsigned int altp2m = info->altp2m;
switch(info->type) {
case LIBXL_DOMAIN_TYPE_HVM:
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v3 1/2] PCI: vmd: Filter resource type bits from shadow register
From: Lorenzo Pieralisi @ 2020-05-29 16:18 UTC (permalink / raw)
To: Derrick, Jonathan
Cc: alex.williamson@redhat.com, linux-pci@vger.kernel.org,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
andrzej.jakowski@linux.intel.com, helgaas@kernel.org, hch@lst.de
In-Reply-To: <163e8cb37ece0c8daa6d6e5fd7fcae47ba4fa437.camel@intel.com>
On Fri, May 29, 2020 at 03:53:37PM +0000, Derrick, Jonathan wrote:
> On Fri, 2020-05-29 at 11:33 +0100, Lorenzo Pieralisi wrote:
> > On Wed, May 27, 2020 at 11:02:39PM -0400, Jon Derrick wrote:
> > > Versions of VMD with the Host Physical Address shadow register use this
> > > register to calculate the bus address offset needed to do guest
> > > passthrough of the domain. This register shadows the Host Physical
> > > Address registers including the resource type bits. After calculating
> > > the offset, the extra resource type bits lead to the VMD resources being
> > > over-provisioned at the front and under-provisioned at the back.
> > >
> > > Example:
> > > pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit]
> > >
> > > Expected:
> > > pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit]
> > >
> > > If other devices are mapped in the over-provisioned front, it could lead
> > > to resource conflict issues with VMD or those devices.
> > >
> > > Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes")
> > > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > > ---
> > > drivers/pci/controller/vmd.c | 6 ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > Hi Jon,
> >
> > it looks like I can take this patch for v5.8 whereas patch 2 depends
> > on the QEMU changes acceptance and should probably wait.
> >
> > Please let me know your thoughts asap and I will try to at least
> > squeeze this patch in.
> >
> > Lorenzo
>
> Hi Lorenzo,
>
> This is fine. Please take Patch 1.
> Patch 2 is harmless without the QEMU changes, but may always need a
> different approach.
Pulled patch 1 into pci/vmd, thanks.
Lorenzo
^ permalink raw reply
* Re: [PATCH rfc v3] New ioctl BTRFS_IOC_GET_CHUNK_INFO.
From: Goffredo Baroncelli @ 2020-05-29 16:23 UTC (permalink / raw)
To: Hans van Kranenburg, dsterba, linux-btrfs, Josef Bacik
In-Reply-To: <c879054a-c002-8b9b-4db5-e32caf8a732b@knorrie.org>
On 5/28/20 11:03 PM, Hans van Kranenburg wrote:
> Hi,
>
> On 5/26/20 10:19 PM, Goffredo Baroncelli wrote:
>> On 5/25/20 7:14 PM, David Sterba wrote:
>>> I'll start with the data structures
[...]
>>>
>>> This looks like a copy of btrfs_chunk and stripe, only removing items
>>> not needed for the chunk information. Rather than copying the
>>> unnecessary fileds like dev_uuid in stripe, this should be designed for
>>> data exchange with the usecase in mind.
>>
>> There are two clients for this api:
>> - btrfs fi us
>> - btrfs dev us
>>
>> We can get rid of:
>> - "offset" fields (2x)
>> - "uuid" fields
>>
>> However the "offset" fields can be used to understand where a logical map
>> is on the physical disks. I am thinking about a graphical tool to show this
>> mapping, which doesn't exits yet -).
>> The offset field may be used as key to get further information (like the chunk
>> usage, see below)
>>
>> Regarding the UUID field, I agree it can be removed because it is redundant (there
>> is already the devid)
>>
>>
>>>
>>> The format does not need follow the exact layout that kernel uses, ie.
>>> chunk info with one embedded stripe and then followed by variable length
>>> array of further stripes. This is convenient in one way but not in
>>> another one. Alternatively each chunk can be emitted as a single entry,
>>> duplicating part of the common fields and adding the stripe-specific
>>> ones. This is for consideration.
>>>
>>> I've looked at my old code doing the chunk dump based on the search
>>> ioctl and found that it also allows to read the chunk usage, with one
>>> extra search to the block group item where the usage is stored. As this
>>> is can be slow, it should be optional. Ie. the main ioctl structure
>>> needs flags where this can be requested.
>>
>> This info could be very useful. I think to something like a balance of
>> chunks which are near filled (or near empty). The question is if we
>> should have a different ioctl.
>
> Do you mean that you want to allow to a non root user to run btrfs balance?
No at all. The balance is an expensive operation that IMHO need root
privileges to be started.
>
> Otherwise, no. IMO convenience functions for quickly retrieving a
> specific subset of data should be created as reusable library functions
> in the calling code, not as a redundant extra IOCTL that has to be
> maintained.
I think that there is a misunderstood. There is no intention to take the
place of the current balance ioctl.
The aim of this ioctl is only to get information about the chunk distribution.
Getting the chunk information could help to perform a better balance.
I.e. a balance which start from the chunk more empty the go forward
processing the chunk more filled. Another case use is to visulize how
the chunk are filled, or how the disks are used..
>
> Hans
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: blk-mq: improvement CPU hotplug (simplified version) v4
From: Jens Axboe @ 2020-05-29 16:23 UTC (permalink / raw)
To: Christoph Hellwig, Ming Lei
Cc: linux-block, John Garry, Bart Van Assche, Hannes Reinecke,
Thomas Gleixner
In-Reply-To: <20200529135315.199230-1-hch@lst.de>
On 5/29/20 7:53 AM, Christoph Hellwig wrote:
> Hi all,
>
> this series ensures I/O is quiesced before a cpu and thus the managed
> interrupt handler is shut down.
>
> This patchset tries to address the issue by the following approach:
>
> - before the last cpu in hctx->cpumask is going to offline, mark this
> hctx as inactive
>
> - disable preempt during allocating tag for request, and after tag is
> allocated, check if this hctx is inactive. If yes, give up the
> allocation and try remote allocation from online CPUs
>
> - before hctx becomes inactive, drain all allocated requests on this
> hctx
>
> The guts of the changes are from Ming Lei, I just did a bunch of prep
> cleanups so that they can fit in more nicely. The series also depends
> on my "avoid a few q_usage_counter roundtrips v3" series.
>
> Thanks John Garry for running lots of tests on arm64 with this previous
> version patches and co-working on investigating all kinds of issues.
Applied, thanks.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 3/4] scsi: move target device list to xarray
From: Douglas Gilbert @ 2020-05-29 16:24 UTC (permalink / raw)
To: Hannes Reinecke, Matthew Wilcox
Cc: Martin K. Petersen, Christoph Hellwig, Daniel Wagner,
Johannes Thumshirn, James Bottomley, linux-scsi
In-Reply-To: <6ed49962-479e-ced7-16b4-095c8f5f70d6@suse.de>
On 2020-05-29 8:46 a.m., Hannes Reinecke wrote:
> On 5/29/20 1:21 PM, Matthew Wilcox wrote:
>> On Fri, May 29, 2020 at 08:50:21AM +0200, Hannes Reinecke wrote:
>>>> I meant just use xa_alloc() for everything instead of using xa_insert for
>>>> 0-255.
>>>>
>>> But then I'll have to use xa_find() to get to the actual element as the 1:1
>>> mapping between SCSI LUN and array index is lost.
>>> And seeing that most storage arrays will expose only up to 256 LUNs I
>>> thought this was a good improvement on lookup.
>>> Of course, this only makes sense if xa_load() is more efficient than
>>> xa_find(). If not then of course it's a bit futile.
>>
>> xa_load() is absolutely more efficient than xa_find(). It's just a
>> question of whether it matters ;-) Carry on ...
>>
> Thanks. I will.
>
> BTW, care to update the documentation?
>
> * Return: 0 on success, -ENOMEM if memory could not be allocated or
> * -EBUSY if there are no free entries in @limit.
> */
> int __xa_alloc(struct xarray *xa, u32 *id, void *entry,
> struct xa_limit limit, gfp_t gfp)
> {
> XA_STATE(xas, xa, 0);
>
> if (WARN_ON_ONCE(xa_is_advanced(entry)))
> return -EINVAL;
> if (WARN_ON_ONCE(!xa_track_free(xa)))
> return -EINVAL;
>
> So looks as if the documentation is in need of updating to cover -EINVAL.
> And, please, state somewhere that whenever you want to use xa_alloc() you _need_
> to specify XA_ALLOC_FLAGS in xa_init_flags(), otherwise
> you trip across the above.
>
> It's not entirely obvious, and took me the better half of a day to figure out.
Ditto for me. At the time I did relay my frustration to Matthew who did
address it in the documentation. Another one is that xa_find*() requires the
XA_PRESENT mark, even when you are not using marks (or haven't yet learnt
about them ...). A clearer demarcation of the two xarray modes (i.e. either
the user supplies the index, or xarray does) would be helpful. That mode
impacts which parts of the xarray interface are used, for example in the sg
driver rewrite, xarrays are used for all collections but if memory serves,
there isn't a single xa_load() or xa_store() call.
But writing technical documentation is difficult. Very few third parties step
up to help, leaving the designer/implementer to do it. And it is extremely
difficult for someone who knows the code backwards (and where the skeletons are
buried) to stand on their heads and present the information in a pedagogic
manner.
Also traditional code documentation uses 7 bit ASCII text and "ACSII art" in
a sort of nod to earlier generations of programmers. Surely more modern
techniques, including colour diagrams and even animations, should now be
encouraged. Maybe when compilers start accepting html :-)
Doug Gilbert
P.S. I have tried to practice what I preach:
http://sg.danny.cz/sg/sg_v40.html
^ permalink raw reply
* Re: [PATCH v3] x86/PV: remove unnecessary toggle_guest_pt() overhead
From: Andrew Cooper @ 2020-05-29 16:24 UTC (permalink / raw)
To: Jan Beulich, xen-devel@lists.xenproject.org; +Cc: Wei Liu, Roger Pau Monné
In-Reply-To: <a6084473-2fb7-4106-66a4-d180ef483314@suse.com>
On 22/05/2020 11:07, Jan Beulich wrote:
> On 21.05.2020 18:46, Andrew Cooper wrote:
>> On 05/05/2020 07:16, Jan Beulich wrote:
>>> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
>>> expensive (but still needed only for the toggle_guest_mode() path), the
>>> effect of the latter on the exit-to-guest path is not insignificant.
>>> Move the logic into toggle_guest_mode(), on the basis that
>>> toggle_guest_pt() will always be invoked in pairs, yet we can't safely
>>> undo the setting of root_pgt_changed during the second of these
>>> invocations.
>>>
>>> While at it, add a comment ahead of toggle_guest_pt() to clarify its
>>> intended usage.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> I'm still of the opinion that the commit message wants rewriting to get
>> the important points across clearly.
>>
>> And those are that toggle_guest_pt() is called in pairs specifically to
>> read kernel data structures when emulating a userspace action, and that
>> this doesn't modify cr3 from the guests point of view, and therefore
>> doesn't need the resync on exit-to-guest path.
> Is this
>
> "toggle_guest_pt() is called in pairs, to read guest kernel data
> structures when emulating a guest userspace action. Hence this doesn't
> modify cr3 from the guest's point of view, and therefore doesn't need
> any resync on the exit-to-guest path. Therefore move the updating of
> ->pv_cr3 and ->root_pgt_changed into toggle_guest_mode(), since undoing
> the changes during the second of these invocations wouldn't be a safe
> thing to do."
>
> any better?
Yes - that will do.
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: Enable autoneg bypass for 1000BaseX/2500BaseX ports
From: Andrew Lunn @ 2020-05-29 16:25 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Thomas Bogendoerfer, David S. Miller, Jakub Kicinski, netdev,
linux-kernel
In-Reply-To: <20200529155121.GA1551@shell.armlinux.org.uk>
> I wonder how much risk there is to changing that, so we force the link
> down if phylink says the link should be down, otherwise we force the
> speed/duplex, disable AN, and allow the link to come up depending on
> the serdes status. It /sounds/ like something sane to do.
Hi Russell
I actually did this for mv88e6xxx in a patchset for ZII devel B. It
was determining link based on SFP LOS, which we know is unreliable. It
said there was link even when the SERDES had lost link.
I did it by making use of the fixed-link state call back, since it was
a quick and dirty patch. But it might make more sense for the MAC to
call phylink_mac_change() for change in PCS state? Or add a PCS
specific.
Andrew
^ permalink raw reply
* Re: pull request: mt76 2019-05-22
From: Felix Fietkau @ 2020-05-29 16:26 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <875zceu90v.fsf@codeaurora.org>
On 2020-05-29 16:10, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> Hi Kalle,
>>
>> here's another pull request for 5.8, replacing the previous one.
>>
>> - Felix
>>
>> The following changes since commit 50ce4c099bebf56be86c9448f7f4bcd34f33663c:
>>
>> sctp: fix typo sctp_ulpevent_nofity_peer_addr_change (2020-05-27 15:08:02 -0700)
>>
>> are available in the Git repository at:
>>
>> https://github.com/nbd168/wireless tags/mt76-for-kvalo-2020-05-28
>>
>> for you to fetch changes up to d9045b18cd445e0d0a53903ffd5d79793d9df59e:
>>
>> mt76: mt7915: remove set but not used variable 'msta' (2020-05-28 17:57:25 +0200)
>>
>> ----------------------------------------------------------------
>> mt76 patches for 5.8
>>
>> * fixes for sparse warnings
>> * DBDC fixes
>> * mt7663 remain-on-channel support
>> * mt7915 spatial reuse support
>> * mt7915 radiotap fix
>> * station wcid allocation fix
>> * mt7663 powersave fix
>> * mt7663 scan fix
>> * mt7611n support
>> * cleanup
>>
>> ----------------------------------------------------------------
>
> One commit has the Cc field by accident, but no need to resend because
> of this. Just check your workflow.
Sorry about that. I will be more careful about that sort of thing.
Thanks,
- Felix
^ permalink raw reply
* Re: [PATCH 1/1] libdmmp: Add support for upcoming json-c 0.14.0.
From: Martin Wilck @ 2020-05-29 16:26 UTC (permalink / raw)
To: bmarzins@redhat.com
Cc: mail@eworm.de, dm-devel@redhat.com, xose.vazquez@gmail.com,
besser82@fedoraproject.org
In-Reply-To: <20200529161959.GF5907@octiron.msp.redhat.com>
On Fri, 2020-05-29 at 11:19 -0500, Benjamin Marzinski wrote:
> On Fri, May 29, 2020 at 09:12:30AM +0000, Martin Wilck wrote:
> >
> > Did you see
> > https://www.redhat.com/archives/dm-devel/2020-May/msg00261.html ?
>
> Nope. Overlooked it. My bad. I'm fine with any version that compiles.
> Either stdbool or int is fine.
Ok. I'll take the liberty to apply mine on my upstream-queue branch,
then. Let Christophe have the final say when he merges next time.
Martin
--
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix
Imendörffer
^ permalink raw reply
* Re: [PATCH 4/4] btrfs: add preferred_metadata mode
From: Goffredo Baroncelli @ 2020-05-29 16:26 UTC (permalink / raw)
To: Hans van Kranenburg, linux-btrfs
Cc: Michael, Hugo Mills, Martin Svec, Wang Yugui, Paul Jones,
Adam Borowski, Zygo Blaxell, Goffredo Baroncelli
In-Reply-To: <61d2188a-290c-5d6f-ec32-6cacd3f63ce8@knorrie.org>
On 5/29/20 12:02 AM, Hans van Kranenburg wrote:
> Hi,
>
> On 5/28/20 8:34 PM, Goffredo Baroncelli wrote:
>> From: Goffredo Baroncelli <kreijack@inwind.it>
>>
>> When this mode is enabled,
>
> The commit message does not mention if this is either only a convenience
> during development and testing of the feature to be able to quickly turn
> it on/off, or if you intend to have this into the final change set.
Good question. IMHO for the initial devel phase I think that it is useful to have
a preferred_metadata disk (opt-in). Then we could reverse the logic and
default to preferred_metadata. Of course then we will have a
no-preferred_metadata flag (opt-out)
>
>> the allocation policy of the chunk
>> is so modified:
>> - allocation of metadata chunk: priority is given to preferred_metadata
>> disks.
>> - allocation of data chunk: priority is given to a non preferred_metadata
>> disk.
>>
>> When a striped profile is involved (like RAID0,5,6), the logic
>> is a bit more complex. If there are enough disks, the data profiles
>> are stored on the non preferred_metadata disks; instead the metadata
>> profiles are stored on the preferred_metadata disk.
>> If the disks are not enough, then the profile is allocated on all
>> the disks.
>>
>> Example: assuming that sda, sdb, sdc are ssd disks, and sde, sdf are
>> non preferred_metadata ones.
>> A data profile raid6, will be stored on sda, sdb, sdc, sde, sdf (sde
>> and sdf are not enough to host a raid5 profile).
>> A metadata profile raid6, will be stored on sda, sdb, sdc (these
>> are enough to host a raid6 profile).
>>
>> To enable this mode pass -o dedicated_metadata at mount time.
>
> Is it dedicated_metadata or preferred_metadata?
It was an copy&paste error. It should be preferred_metadata
>
>> Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
>> ---
>> fs/btrfs/ctree.h | 1 +
>> fs/btrfs/super.c | 8 +++++
>> fs/btrfs/volumes.c | 89 ++++++++++++++++++++++++++++++++++++++++++++--
>> fs/btrfs/volumes.h | 1 +
>> 4 files changed, 97 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
>> index 03ea7370aea7..779760fd27b1 100644
>> --- a/fs/btrfs/ctree.h
>> +++ b/fs/btrfs/ctree.h
>> @@ -1239,6 +1239,7 @@ static inline u32 BTRFS_MAX_XATTR_SIZE(const struct btrfs_fs_info *info)
>> #define BTRFS_MOUNT_NOLOGREPLAY (1 << 27)
>> #define BTRFS_MOUNT_REF_VERIFY (1 << 28)
>> #define BTRFS_MOUNT_DISCARD_ASYNC (1 << 29)
>> +#define BTRFS_MOUNT_PREFERRED_METADATA (1 << 30)
>>
>> #define BTRFS_DEFAULT_COMMIT_INTERVAL (30)
>> #define BTRFS_DEFAULT_MAX_INLINE (2048)
>> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
>> index 438ecba26557..80700dc9dcf8 100644
>> --- a/fs/btrfs/super.c
>> +++ b/fs/btrfs/super.c
>> @@ -359,6 +359,7 @@ enum {
>> #ifdef CONFIG_BTRFS_FS_REF_VERIFY
>> Opt_ref_verify,
>> #endif
>> + Opt_preferred_metadata,
>> Opt_err,
>> };
>>
>> @@ -430,6 +431,7 @@ static const match_table_t tokens = {
>> #ifdef CONFIG_BTRFS_FS_REF_VERIFY
>> {Opt_ref_verify, "ref_verify"},
>> #endif
>> + {Opt_preferred_metadata, "preferred_metadata"},
>> {Opt_err, NULL},
>> };
>>
>> @@ -881,6 +883,10 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options,
>> btrfs_set_opt(info->mount_opt, REF_VERIFY);
>> break;
>> #endif
>> + case Opt_preferred_metadata:
>> + btrfs_set_and_info(info, PREFERRED_METADATA,
>> + "enabling preferred_metadata");
>> + break;
>> case Opt_err:
>> btrfs_err(info, "unrecognized mount option '%s'", p);
>> ret = -EINVAL;
>> @@ -1403,6 +1409,8 @@ static int btrfs_show_options(struct seq_file *seq, struct dentry *dentry)
>> #endif
>> if (btrfs_test_opt(info, REF_VERIFY))
>> seq_puts(seq, ",ref_verify");
>> + if (btrfs_test_opt(info, PREFERRED_METADATA))
>> + seq_puts(seq, ",preferred_metadata");
>> seq_printf(seq, ",subvolid=%llu",
>> BTRFS_I(d_inode(dentry))->root->root_key.objectid);
>> seq_puts(seq, ",subvol=");
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index 5265f54c2931..c68efb15e473 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -4770,6 +4770,56 @@ static int btrfs_cmp_device_info(const void *a, const void *b)
>> return 0;
>> }
>>
>> +/*
>> + * sort the devices in descending order by preferred_metadata,
>> + * max_avail, total_avail
>> + */
>> +static int btrfs_cmp_device_info_metadata(const void *a, const void *b)
>> +{
>> + const struct btrfs_device_info *di_a = a;
>> + const struct btrfs_device_info *di_b = b;
>> +
>> + /* metadata -> preferred_metadata first */
>> + if (di_a->preferred_metadata && !di_b->preferred_metadata)
>> + return -1;
>> + if (!di_a->preferred_metadata && di_b->preferred_metadata)
>> + return 1;
>> + if (di_a->max_avail > di_b->max_avail)
>> + return -1;
>> + if (di_a->max_avail < di_b->max_avail)
>> + return 1;
>> + if (di_a->total_avail > di_b->total_avail)
>> + return -1;
>> + if (di_a->total_avail < di_b->total_avail)
>> + return 1;
>> + return 0;
>> +}
>> +
>> +/*
>> + * sort the devices in descending order by !preferred_metadata,
>> + * max_avail, total_avail
>> + */
>> +static int btrfs_cmp_device_info_data(const void *a, const void *b)
>> +{
>> + const struct btrfs_device_info *di_a = a;
>> + const struct btrfs_device_info *di_b = b;
>> +
>> + /* data -> preferred_metadata last */
>> + if (di_a->preferred_metadata && !di_b->preferred_metadata)
>> + return 1;
>> + if (!di_a->preferred_metadata && di_b->preferred_metadata)
>> + return -1;
>> + if (di_a->max_avail > di_b->max_avail)
>> + return -1;
>> + if (di_a->max_avail < di_b->max_avail)
>> + return 1;
>> + if (di_a->total_avail > di_b->total_avail)
>> + return -1;
>> + if (di_a->total_avail < di_b->total_avail)
>> + return 1;
>> + return 0;
>> +}
>> +
>> static void check_raid56_incompat_flag(struct btrfs_fs_info *info, u64 type)
>> {
>> if (!(type & BTRFS_BLOCK_GROUP_RAID56_MASK))
>> @@ -4885,6 +4935,7 @@ static int gather_device_info(struct btrfs_fs_devices *fs_devices,
>> int ndevs = 0;
>> u64 max_avail;
>> u64 dev_offset;
>> + int nr_preferred_metadata = 0;
>>
>> /*
>> * in the first pass through the devices list, we gather information
>> @@ -4937,15 +4988,49 @@ static int gather_device_info(struct btrfs_fs_devices *fs_devices,
>> devices_info[ndevs].max_avail = max_avail;
>> devices_info[ndevs].total_avail = total_avail;
>> devices_info[ndevs].dev = device;
>> + devices_info[ndevs].preferred_metadata = !!(device->type &
>> + BTRFS_DEV_PREFERRED_METADATA);
>> + if (devices_info[ndevs].preferred_metadata)
>> + nr_preferred_metadata++;
>> ++ndevs;
>> }
>> ctl->ndevs = ndevs;
>>
>> + BUG_ON(nr_preferred_metadata > ndevs);
>> /*
>> * now sort the devices by hole size / available space
>> */
>> - sort(devices_info, ndevs, sizeof(struct btrfs_device_info),
>> - btrfs_cmp_device_info, NULL);
>> + if (((ctl->type & BTRFS_BLOCK_GROUP_DATA) &&
>> + (ctl->type & BTRFS_BLOCK_GROUP_METADATA)) ||
>> + !btrfs_test_opt(info, PREFERRED_METADATA)) {
>> + /* mixed bg or PREFERRED_METADATA not set */
>> + sort(devices_info, ctl->ndevs, sizeof(struct btrfs_device_info),
>> + btrfs_cmp_device_info, NULL);
>> + } else {
>> + /*
>> + * if PREFERRED_METADATA is set, sort the device considering
>> + * also the kind (preferred_metadata or not). Limit the
>> + * availables devices to the ones of the same kind, to avoid
>> + * that a striped profile, like raid5, spreads to all kind of
>> + * devices.
>> + * It is allowed to use different kinds of devices if the ones
>> + * of the same kind are not enough alone.
>> + */
>> + if (ctl->type & BTRFS_BLOCK_GROUP_DATA) {
>> + int nr_data = ctl->ndevs - nr_preferred_metadata;
>> + sort(devices_info, ctl->ndevs,
>> + sizeof(struct btrfs_device_info),
>> + btrfs_cmp_device_info_data, NULL);
>> + if (nr_data >= ctl->devs_min)
>> + ctl->ndevs = nr_data;
>> + } else { /* non data -> metadata and system */
>> + sort(devices_info, ctl->ndevs,
>> + sizeof(struct btrfs_device_info),
>> + btrfs_cmp_device_info_metadata, NULL);
>> + if (nr_preferred_metadata >= ctl->devs_min)
>> + ctl->ndevs = nr_preferred_metadata;
>> + }
>> + }
>>
>> return 0;
>> }
>> diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
>> index 0ac5bf2b95e6..d39c3b0e7569 100644
>> --- a/fs/btrfs/volumes.h
>> +++ b/fs/btrfs/volumes.h
>> @@ -347,6 +347,7 @@ struct btrfs_device_info {
>> u64 dev_offset;
>> u64 max_avail;
>> u64 total_avail;
>> + int preferred_metadata:1;
>> };
>>
>> struct btrfs_raid_attr {
>>
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: [PATCH 4.19 69/81] misc: rtsx: Add short delay after exit from ASPM
From: Pavel Machek @ 2020-05-29 16:26 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, stable, Klaus Doth
In-Reply-To: <20200526183934.709077655@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
Hi!
> Signed-off-by: Klaus Doth <kdlnx@doth.eu>
> Cc: stable <stable@vger.kernel.org>
> Link: https://lore.kernel.org/r/4434eaa7-2ee3-a560-faee-6cee63ebd6d4@doth.eu
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> +++ b/drivers/misc/cardreader/rtsx_pcr.c
> @@ -155,6 +155,9 @@ static void rtsx_comm_pm_full_on(struct
>
> rtsx_disable_aspm(pcr);
>
> + /* Fixes DMA transfer timout issue after disabling ASPM on RTS5260 */
> + msleep(1);
> +
There's typo in comment, should be "timeout".
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Pavel Machek @ 2020-05-29 16:27 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Rob Herring, Greg Kroah-Hartman,
Rafael J . Wysocki, linux-pm, devicetree, linux-kernel, kernel
In-Reply-To: <20200513185615.508236-1-sebastian.reichel@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
Hi!
> This patchset improves support for SBS compliant batteries. Due to
> the changes, the battery now exposes 32 power supply properties and
> (un)plugging it generates a backtrace containing the following message
> without the first patch in this series:
>
> ---------------------------
> WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
> add_uevent_var: too many keys
> ---------------------------
>
> For references this is what an SBS battery status looks like after
> the patch series has been applied:
>
> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
Is that correct, BTW? sounds like these should not be equal...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 for-4.14] tools/libxl: fix setting altp2m param broken by 1e9bc407cf0
From: Andrew Cooper @ 2020-05-29 16:27 UTC (permalink / raw)
To: Tamas K Lengyel, xen-devel; +Cc: Anthony PERARD, Ian Jackson, Wei Liu
In-Reply-To: <20200529162234.16824-1-tamas@tklengyel.com>
On 29/05/2020 17:22, Tamas K Lengyel wrote:
> The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
> boolean. This is incorrect and breaks external-only usecases of altp2m that
> is set with a value of 2.
>
> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Sorry for breaking it to begin with.
^ permalink raw reply
* Re: [PATCH v3 4/5] arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
From: Pavel Machek @ 2020-05-29 16:27 UTC (permalink / raw)
To: Ondrej Jirman
Cc: linux-sunxi, Thierry Reding, Sam Ravnborg, David Airlie,
Daniel Vetter, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Linus Walleij, Icenowy Zheng, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, Samuel Holland, Martijn Braam, Luca Weiss,
Bhushan Shah
In-Reply-To: <20200513212451.1919013-5-megous@megous.com>
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]
Hi!
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.
If it was possible to preserve lux values for individual settings in
the comment somewhere... that would be nice :-).
One day, it would be nice to have brightness settings in lux, so I
could easily set matching levels on multiple devices, for example...
Best regards,
Pavel
> +
> +&backlight {
> + power-supply = <®_ldo_io0>;
> + /*
> + * PWM backlight circuit on this PinePhone revision was changed since
> + * 1.0, and the lowest PWM duty cycle that doesn't lead to backlight
> + * being off is around 20%. Duty cycle for the lowest brightness level
> + * also varries quite a bit between individual boards, so the lowest
> + * value here was chosen as a safe default.
> + */
> + brightness-levels = <
> + 774 793 814 842
> + 882 935 1003 1088
> + 1192 1316 1462 1633
> + 1830 2054 2309 2596
> + 2916 3271 3664 4096>;
> + num-interpolated-steps = <50>;
> + default-brightness-level = <400>;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/5] arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
From: Pavel Machek @ 2020-05-29 16:27 UTC (permalink / raw)
To: Ondrej Jirman
Cc: devicetree, Samuel Holland, David Airlie, Bhushan Shah,
Chen-Yu Tsai, linux-kernel, Martijn Braam, linux-sunxi,
Rob Herring, Thierry Reding, dri-devel, Sam Ravnborg, Luca Weiss,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20200513212451.1919013-5-megous@megous.com>
[-- Attachment #1.1: Type: text/plain, Size: 1265 bytes --]
Hi!
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.
If it was possible to preserve lux values for individual settings in
the comment somewhere... that would be nice :-).
One day, it would be nice to have brightness settings in lux, so I
could easily set matching levels on multiple devices, for example...
Best regards,
Pavel
> +
> +&backlight {
> + power-supply = <®_ldo_io0>;
> + /*
> + * PWM backlight circuit on this PinePhone revision was changed since
> + * 1.0, and the lowest PWM duty cycle that doesn't lead to backlight
> + * being off is around 20%. Duty cycle for the lowest brightness level
> + * also varries quite a bit between individual boards, so the lowest
> + * value here was chosen as a safe default.
> + */
> + brightness-levels = <
> + 774 793 814 842
> + 882 935 1003 1088
> + 1192 1316 1462 1633
> + 1830 2054 2309 2596
> + 2916 3271 3664 4096>;
> + num-interpolated-steps = <50>;
> + default-brightness-level = <400>;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 4/5] arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
From: Pavel Machek @ 2020-05-29 16:27 UTC (permalink / raw)
To: Ondrej Jirman
Cc: devicetree, Samuel Holland, David Airlie, Linus Walleij,
Bhushan Shah, Chen-Yu Tsai, Maxime Ripard, linux-kernel,
Martijn Braam, linux-sunxi, Rob Herring, Thierry Reding,
dri-devel, Daniel Vetter, Sam Ravnborg, Luca Weiss,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20200513212451.1919013-5-megous@megous.com>
[-- Attachment #1.1: Type: text/plain, Size: 1265 bytes --]
Hi!
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.
If it was possible to preserve lux values for individual settings in
the comment somewhere... that would be nice :-).
One day, it would be nice to have brightness settings in lux, so I
could easily set matching levels on multiple devices, for example...
Best regards,
Pavel
> +
> +&backlight {
> + power-supply = <®_ldo_io0>;
> + /*
> + * PWM backlight circuit on this PinePhone revision was changed since
> + * 1.0, and the lowest PWM duty cycle that doesn't lead to backlight
> + * being off is around 20%. Duty cycle for the lowest brightness level
> + * also varries quite a bit between individual boards, so the lowest
> + * value here was chosen as a safe default.
> + */
> + brightness-levels = <
> + 774 793 814 842
> + 882 935 1003 1088
> + 1192 1316 1462 1633
> + 1830 2054 2309 2596
> + 2916 3271 3664 4096>;
> + num-interpolated-steps = <50>;
> + default-brightness-level = <400>;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH bpf-next RFC 1/3] bpf: move struct bpf_devmap_val out of UAPI
From: Jesper Dangaard Brouer @ 2020-05-29 16:28 UTC (permalink / raw)
To: David Ahern
Cc: bpf, netdev, Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
brouer
In-Reply-To: <a0cadc6b-ceb4-c40b-8a02-67b99a665d74@gmail.com>
On Fri, 29 May 2020 10:06:25 -0600
David Ahern <dsahern@gmail.com> wrote:
> On 5/29/20 9:59 AM, Jesper Dangaard Brouer wrote:
> > @@ -60,6 +60,15 @@ struct xdp_dev_bulk_queue {
> > unsigned int count;
> > };
> >
> > +/* DEVMAP values */
> > +struct bpf_devmap_val {
> > + __u32 ifindex; /* device index */
> > + union {
> > + int fd; /* prog fd on map write */
> > + __u32 id; /* prog id on map read */
> > + } bpf_prog;
> > +};
> > +
>
> I can pick up this name change for v4.
Great - I will appreciate, as this will make my patchset compatible
with yours :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH 0/4] Add support for LX TestBox
From: Benedikt Spranger @ 2020-05-29 16:28 UTC (permalink / raw)
To: u-boot
The Testbox board is an open hardware enhancement for the Lamobo R1 router
board. The Testbox board is used in the CI-RT project to manage devices
under test (https://ci-rt.linutronix.de).
Add support for the LX TestBox.
Benedikt Spranger (4):
sunxi: pmic_bus: Refactor pmic_bus_read() and pmic_bus_write()
i2c: mvtwsi: Add Allwinner sun4i compatible
sunxi: pmic_bus: Add DM I2C support
common: Add LX TestBox checks
arch/arm/mach-sunxi/Kconfig | 15 +++++++++++
arch/arm/mach-sunxi/pmic_bus.c | 48 +++++++++++++++++++++++++---------
board/sunxi/board.c | 47 +++++++++++++++++++++++++++++++++
configs/Lamobo_R1_defconfig | 1 +
drivers/i2c/mvtwsi.c | 1 +
5 files changed, 100 insertions(+), 12 deletions(-)
--
2.19.0
^ permalink raw reply
* [PATCH 1/4] sunxi: pmic_bus: Refactor pmic_bus_read() and pmic_bus_write()
From: Benedikt Spranger @ 2020-05-29 16:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200529162839.3544366-1-b.spranger@linutronix.de>
Unify I2C calls to ease the driver model conversion.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
---
arch/arm/mach-sunxi/pmic_bus.c | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
index dea42de833..091c59331b 100644
--- a/arch/arm/mach-sunxi/pmic_bus.c
+++ b/arch/arm/mach-sunxi/pmic_bus.c
@@ -26,6 +26,14 @@
#define AXP223_DEVICE_ADDR 0x3a3
#define AXP223_RUNTIME_ADDR 0x2d
+#ifdef CONFIG_AXP152_POWER
+#define PMIC_I2C_ADDR AXP152_I2C_ADDR
+#elif defined CONFIG_AXP209_POWER
+#define PMIC_I2C_ADDR AXP209_I2C_ADDR
+#else
+#undef PMIC_I2C_ADDR
+#endif
+
int pmic_bus_init(void)
{
/* This cannot be 0 because it is used in SPL before BSS is ready */
@@ -60,35 +68,31 @@ int pmic_bus_init(void)
int pmic_bus_read(u8 reg, u8 *data)
{
-#ifdef CONFIG_AXP152_POWER
- return i2c_read(AXP152_I2C_ADDR, reg, 1, data, 1);
-#elif defined CONFIG_AXP209_POWER
- return i2c_read(AXP209_I2C_ADDR, reg, 1, data, 1);
+#ifdef PMIC_I2C_ADDR
+ return i2c_read(PMIC_I2C_ADDR, reg, 1, data, 1);
#elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
# ifdef CONFIG_MACH_SUN6I
return p2wi_read(reg, data);
-# elif defined CONFIG_MACH_SUN8I_R40
- return i2c_read(AXP209_I2C_ADDR, reg, 1, data, 1);
# else
return rsb_read(AXP223_RUNTIME_ADDR, reg, data);
# endif
+#else
+#error "unknown PMIC"
#endif
}
int pmic_bus_write(u8 reg, u8 data)
{
-#ifdef CONFIG_AXP152_POWER
- return i2c_write(AXP152_I2C_ADDR, reg, 1, &data, 1);
-#elif defined CONFIG_AXP209_POWER
- return i2c_write(AXP209_I2C_ADDR, reg, 1, &data, 1);
+#ifdef PMIC_I2C_ADDR
+ return i2c_write(PMIC_I2C_ADDR, reg, 1, &data, 1);
#elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
# ifdef CONFIG_MACH_SUN6I
return p2wi_write(reg, data);
-# elif defined CONFIG_MACH_SUN8I_R40
- return i2c_write(AXP209_I2C_ADDR, reg, 1, &data, 1);
# else
return rsb_write(AXP223_RUNTIME_ADDR, reg, data);
# endif
+#else
+#error "unknown PMIC"
#endif
}
--
2.19.0
^ permalink raw reply related
* [PATCH 2/4] i2c: mvtwsi: Add Allwinner sun4i compatible
From: Benedikt Spranger @ 2020-05-29 16:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200529162839.3544366-1-b.spranger@linutronix.de>
Add the compatible string for the Allwinner A10 i2c controller.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
---
drivers/i2c/mvtwsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index d3cc9b9d83..57cd442eee 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -878,6 +878,7 @@ static const struct udevice_id mvtwsi_i2c_ids[] = {
{ .compatible = "marvell,mv64xxx-i2c", },
{ .compatible = "marvell,mv78230-i2c", },
{ .compatible = "allwinner,sun6i-a31-i2c", },
+ { .compatible = "allwinner,sun4i-a10-i2c", },
{ /* sentinel */ }
};
--
2.19.0
^ permalink raw reply related
* [PATCH 3/4] sunxi: pmic_bus: Add DM I2C support
From: Benedikt Spranger @ 2020-05-29 16:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200529162839.3544366-1-b.spranger@linutronix.de>
Add support for U-Boot DM.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
---
arch/arm/mach-sunxi/pmic_bus.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
index 091c59331b..8ecd037528 100644
--- a/arch/arm/mach-sunxi/pmic_bus.c
+++ b/arch/arm/mach-sunxi/pmic_bus.c
@@ -34,6 +34,8 @@
#undef PMIC_I2C_ADDR
#endif
+struct udevice *pmic_dev __section(.data) = NULL;
+
int pmic_bus_init(void)
{
/* This cannot be 0 because it is used in SPL before BSS is ready */
@@ -43,6 +45,16 @@ int pmic_bus_init(void)
if (!needs_init)
return 0;
+#if defined PMIC_I2C_ADDR && defined CONFIG_DM_I2C
+ struct udevice *dev = NULL;
+ int rc;
+
+ rc = i2c_get_chip_for_busnum(0, PMIC_I2C_ADDR, 1, &dev);
+ if (rc)
+ return rc;
+ pmic_dev = dev;
+#endif
+
#if defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
# ifdef CONFIG_MACH_SUN6I
p2wi_init();
@@ -69,7 +81,11 @@ int pmic_bus_init(void)
int pmic_bus_read(u8 reg, u8 *data)
{
#ifdef PMIC_I2C_ADDR
+#ifndef CONFIG_DM_I2C
return i2c_read(PMIC_I2C_ADDR, reg, 1, data, 1);
+#else
+ return dm_i2c_read(pmic_dev, reg, data, 1);
+#endif
#elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
# ifdef CONFIG_MACH_SUN6I
return p2wi_read(reg, data);
@@ -84,7 +100,11 @@ int pmic_bus_read(u8 reg, u8 *data)
int pmic_bus_write(u8 reg, u8 data)
{
#ifdef PMIC_I2C_ADDR
+#ifndef CONFIG_DM_I2C
return i2c_write(PMIC_I2C_ADDR, reg, 1, &data, 1);
+#else
+ return dm_i2c_read(pmic_dev, reg, &data, 1);
+#endif
#elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER
# ifdef CONFIG_MACH_SUN6I
return p2wi_write(reg, data);
--
2.19.0
^ permalink raw reply related
* [PATCH 4/4] common: Add LX TestBox checks
From: Benedikt Spranger @ 2020-05-29 16:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200529162839.3544366-1-b.spranger@linutronix.de>
The TestBox board is an open hardware enhancement for the Lamobo R1 router
board. The Testbox board is used in the CI-RT project to manage devices
under test (https://ci-rt.linutronix.de).
The hardware project is located at https://github.com/ci-rt/testbox-shield
Check if the hardware is present and use the appropriate device tree file.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
---
arch/arm/mach-sunxi/Kconfig | 15 ++++++++++++
board/sunxi/board.c | 47 +++++++++++++++++++++++++++++++++++++
configs/Lamobo_R1_defconfig | 1 +
3 files changed, 63 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index be0822bfb7..970fa0fae2 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1010,4 +1010,19 @@ config PINE64_DT_SELECTION
option, the device tree selection code specific to Pine64 which
utilizes the DRAM size will be enabled.
+config LXTESTBOX
+ bool "Support for LX TestBox"
+ depends on MACH_SUN7I
+ select I2C2_ENABLE
+ select DM_I2C
+ help
+ The LX TestBox board is an open hardware enhancement for the
+ Lamobo R1 router board. The TestBox board is used in the CI-RT
+ project to manage devices under test (https://ci-rt.linutronix.de).
+
+config LXTESTBOX_DEVICE_TREE
+ string "LX TestBox default device tree"
+ default "sun7i-a20-linutronix-testbox-v2.dtb"
+ help
+ LX TestBox default device tree name.
endif
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index f32e8f582f..4645798bcd 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -43,6 +43,17 @@
#include <spl.h>
#include <sy8106a.h>
#include <asm/setup.h>
+#include <dm/uclass.h>
+#include <i2c.h>
+
+struct lxtestbox_eeprom {
+ u32 magic;
+ u8 version;
+ char serial[7];
+ u32 crc;
+} __packed;
+
+#define LXTESTBOX_I2C_EEPROM_MAGIC 0x6274584c
#if defined CONFIG_VIDEO_LCD_PANEL_I2C && !(defined CONFIG_SPL_BUILD)
/* So that we can use pin names in Kconfig and sunxi_name_to_gpio() */
@@ -839,6 +850,42 @@ static void setup_environment(const void *fdt)
env_set("serial#", serial_string);
}
}
+
+#ifdef CONFIG_LXTESTBOX
+ debug("Check for LX TestBox...");
+ if (!strcmp(env_get("fdtfile"), CONFIG_DEFAULT_DEVICE_TREE ".dtb")) {
+ struct lxtestbox_eeprom moep;
+ struct udevice *bus, *dev;
+ int ret;
+
+ ret = uclass_get_device_by_name(UCLASS_I2C,
+ "i2c at 1c2b400", &bus);
+ if (ret) {
+ printf("Cannot get I2C bus: %i\n", ret);
+ return;
+ }
+
+ ret = i2c_get_chip(bus, 0x50, 1, &dev);
+ if (ret) {
+ printf("Cannot get I2C chip: %i\n", ret);
+ return;
+ }
+
+ ret = dm_i2c_read(dev, 0, (u8 *)&moep, sizeof(moep));
+ if (ret) {
+ printf("cannot read EEPROM: %i\n", ret);
+ return;
+ }
+
+ if (moep.magic != LXTESTBOX_I2C_EEPROM_MAGIC) {
+ printf("bad EEPROM magic number (%08x, should be %08x)\n",
+ moep.magic, LXTESTBOX_I2C_EEPROM_MAGIC);
+ return;
+ }
+ debug("found.\n");
+ env_set("fdtfile", CONFIG_LXTESTBOX_DEVICE_TREE);
+ }
+#endif
}
int misc_init_r(void)
diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index 34db56f79b..d74032e1e5 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -7,6 +7,7 @@ CONFIG_MACPWR="PH23"
CONFIG_MMC0_CD_PIN="PH10"
CONFIG_SATAPWR="PB3"
CONFIG_GMAC_TX_DELAY=4
+CONFIG_LXTESTBOX=y
CONFIG_AHCI=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_I2C_SUPPORT=y
--
2.19.0
^ permalink raw reply related
* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Pavel Machek @ 2020-05-29 16:28 UTC (permalink / raw)
To: Martin Kepplinger
Cc: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>
[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]
Hi!
> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
>
> Add a devicetree description for the Librem 5 phone. The early batches
> that have been sold are supported as well as the mass-produced device
> available later this year, see https://puri.sm/products/librem-5/
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> + blue {
> + label = "phone:blue:front";
> + label = "phone:green:front";
> + label = "phone:red:front";
Droid 4 uses "status-led:{red,green,blue}". Could this use same
naming?
> + label = "lm3560:flash";
> + label = "lm3560:torch";
This is one LED, right? I'm pretty sure we don't want lm3560 in the
name... "main-camera:flash" would be better. Even better would be
something that's already in use.
> + label = "white:backlight_cluster";
Make this ":backlight", please. Again, we want something that's
already used.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Pavel Machek @ 2020-05-29 16:28 UTC (permalink / raw)
To: Martin Kepplinger
Cc: robh, kernel, Anson.Huang, devicetree, shawnguo, s.hauer, angus,
linux-kernel, linux-imx, kernel, mchehab, festevam, agx,
linux-arm-kernel
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>
[-- Attachment #1.1: Type: text/plain, Size: 1342 bytes --]
Hi!
> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
>
> Add a devicetree description for the Librem 5 phone. The early batches
> that have been sold are supported as well as the mass-produced device
> available later this year, see https://puri.sm/products/librem-5/
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> + blue {
> + label = "phone:blue:front";
> + label = "phone:green:front";
> + label = "phone:red:front";
Droid 4 uses "status-led:{red,green,blue}". Could this use same
naming?
> + label = "lm3560:flash";
> + label = "lm3560:torch";
This is one LED, right? I'm pretty sure we don't want lm3560 in the
name... "main-camera:flash" would be better. Even better would be
something that's already in use.
> + label = "white:backlight_cluster";
Make this ":backlight", please. Again, we want something that's
already used.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v3 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
From: Jack Pham @ 2020-05-29 16:28 UTC (permalink / raw)
To: Wesley Cheng
Cc: robh+dt, bjorn.andersson, balbi, gregkh, agross, linux-kernel,
linux-arm-msm, devicetree, linux-usb
In-Reply-To: <1590630363-3934-2-git-send-email-wcheng@codeaurora.org>
Hi Wesley,
On Wed, May 27, 2020 at 06:46:01PM -0700, Wesley Cheng wrote:
> Some devices have USB compositions which may require multiple endpoints
> that support EP bursting. HW defined TX FIFO sizes may not always be
> sufficient for these compositions. By utilizing flexible TX FIFO
> allocation, this allows for endpoints to request the required FIFO depth to
> achieve higher bandwidth. With some higher bMaxBurst configurations, using
> a larger TX FIFO size results in better TX throughput.
>
> Ensure that one TX FIFO is reserved for every IN endpoint. This allows for
> the FIFO logic to prevent running out of FIFO space.
>
> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
> ---
<snip>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 00746c2..9b09528 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -540,6 +540,117 @@ static int dwc3_gadget_start_config(struct dwc3_ep *dep)
> return 0;
> }
>
> +/*
> + * dwc3_gadget_resize_tx_fifos - reallocate fifo spaces for current use-case
> + * @dwc: pointer to our context structure
> + *
> + * This function will a best effort FIFO allocation in order
> + * to improve FIFO usage and throughput, while still allowing
> + * us to enable as many endpoints as possible.
> + *
> + * Keep in mind that this operation will be highly dependent
> + * on the configured size for RAM1 - which contains TxFifo -,
> + * the amount of endpoints enabled on coreConsultant tool, and
> + * the width of the Master Bus.
> + *
> + * In general, FIFO depths are represented with the following equation:
> + *
> + * fifo_size = mult * ((max_packet + mdwidth)/mdwidth + 1) + 1
> + *
> + * Conversions can be done to the equation to derive the number of packets that
> + * will fit to a particular FIFO size value.
> + */
> +static int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc, struct dwc3_ep *dep)
The 'dep' param should be sufficient; we can just get 'dwc' from
dep->dwc. That will make it more clear this function operates on each
endpoint that needs resizing.
> +{
> + int ram1_depth, mdwidth, fifo_0_start, tmp, num_in_ep;
> + int min_depth, remaining, fifo_size, mult = 1, fifo, max_packet = 1024;
> +
> + if (!dwc->needs_fifo_resize)
> + return 0;
> +
> + /* resize IN endpoints except ep0 */
> + if (!usb_endpoint_dir_in(dep->endpoint.desc) || dep->number <= 1)
> + return 0;
> +
> + /* Don't resize already resized IN endpoint */
> + if (dep->fifo_depth)
> + return 0;
> +
> + ram1_depth = DWC3_RAM1_DEPTH(dwc->hwparams.hwparams7);
> + mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
> + /* MDWIDTH is represented in bits, we need it in bytes */
> + mdwidth >>= 3;
> +
> + if (((dep->endpoint.maxburst > 1) &&
> + usb_endpoint_xfer_bulk(dep->endpoint.desc))
> + || usb_endpoint_xfer_isoc(dep->endpoint.desc))
> + mult = 3;
> +
> + if ((dep->endpoint.maxburst > 6) &&
> + usb_endpoint_xfer_bulk(dep->endpoint.desc)
> + && dwc3_is_usb31(dwc))
> + mult = 6;
> +
> + /* FIFO size for a single buffer */
> + fifo = (max_packet + mdwidth)/mdwidth;
> + fifo++;
> +
> + /* Calculate the number of remaining EPs w/o any FIFO */
> + num_in_ep = dwc->num_eps/2;
> + num_in_ep -= dwc->num_ep_resized;
> + /* Ignore EP0 IN */
> + num_in_ep--;
> +
> + /* Reserve at least one FIFO for the number of IN EPs */
> + min_depth = num_in_ep * (fifo+1);
> + remaining = ram1_depth - min_depth - dwc->last_fifo_depth;
> +
> + /* We've already reserved 1 FIFO per EP, so check what we can fit in
> + * addition to it. If there is not enough remaining space, allocate
> + * all the remaining space to the EP.
> + */
> + fifo_size = (mult-1) * fifo;
> + if (remaining < fifo_size) {
> + if (remaining > 0)
> + fifo_size = remaining;
> + else
> + fifo_size = 0;
> + }
> +
> + fifo_size += fifo;
> + fifo_size++;
> + dep->fifo_depth = fifo_size;
> +
> + /* Check if TXFIFOs start at non-zero addr */
> + tmp = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0));
> + fifo_0_start = DWC3_GTXFIFOSIZ_TXFSTADDR(tmp);
> +
> + fifo_size |= (fifo_0_start + (dwc->last_fifo_depth << 16));
> + if (dwc3_is_usb31(dwc))
> + dwc->last_fifo_depth += DWC31_GTXFIFOSIZ_TXFDEP(fifo_size);
> + else
> + dwc->last_fifo_depth += DWC3_GTXFIFOSIZ_TXFDEP(fifo_size);
> +
> + /* Check fifo size allocation doesn't exceed available RAM size. */
> + if (dwc->last_fifo_depth >= ram1_depth) {
> + dev_err(dwc->dev, "Fifosize(%d) > RAM size(%d) %s depth:%d\n",
> + (dwc->last_fifo_depth * mdwidth), ram1_depth,
> + dep->endpoint.name, fifo_size);
Use dev_WARN() here and eliminate the WARN_ON(1) below?
> + if (dwc3_is_usb31(dwc))
> + fifo_size = DWC31_GTXFIFOSIZ_TXFDEP(fifo_size);
> + else
> + fifo_size = DWC3_GTXFIFOSIZ_TXFDEP(fifo_size);
> + dwc->last_fifo_depth -= fifo_size;
> + dep->fifo_depth = 0;
> + WARN_ON(1);
> + return -ENOMEM;
> + }
> +
> + dwc3_writel(dwc->regs, DWC3_GTXFIFOSIZ(dep->number >> 1), fifo_size);
> + dwc->num_ep_resized++;
> + return 0;
> +}
> +
> static int dwc3_gadget_set_ep_config(struct dwc3_ep *dep, unsigned int action)
> {
> const struct usb_ss_ep_comp_descriptor *comp_desc;
> @@ -620,6 +731,10 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action)
> int ret;
>
> if (!(dep->flags & DWC3_EP_ENABLED)) {
> + ret = dwc3_gadget_resize_tx_fifos(dwc, dep);
> + if (ret)
> + return ret;
> +
> ret = dwc3_gadget_start_config(dep);
> if (ret)
> return ret;
Jack
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.