* Xen, EFI and kexec
From: Sylvain Munaut @ 2016-11-09 14:13 UTC (permalink / raw)
To: xen-devel@lists.xen.org
Hi,
A bit of background: What I'm currently trying to do is to network
boot a first linux image in EFI mode (using UEFI network boot), then
from that image, kexec into Xen in EFI mode as well.
It's not working.
When you kexec into another linux in EFI mode, kexec actually passes
some more infos to the kernel to allow it to use EFI mode properly.
IIUC Linux also maps the various EFI ranges at deterministic addresses
because the seting up EFI virtual address mode is only allowed once
per boot and so both the old and new kernel have to use the same
mappings.
I have seen the patch series by Daniel Kiper to add support for
multiboot2 protocol and EFI support for it. This seems like a good
step toward what I'd like to do. Adding multiboot2 support to kexec
user tools seems like something I could do. This should allow Xen to
get the info it needs.
However I don't think that'll be sufficient.
By the time kexec will launch Xen, the first kernel will have done an
"ExitBootServices". And looking at Daniel's patch, that seems to be an
issue.
I'm also not sure if the EFI virtual address mode will be an issue or
not yet. (i.e. Xen uses the physical address mode, but is that usable
after the first linux setup the virtual mode).
Is there anything else I overlooked that will be an issue ?
Is this a use case worth supporting ? (Obviously I think so, but I'm biased :p)
And if I'm looking at it the wrong way, what way should I be looking at it ?
Cheers,
Sylvain Munaut
PS: I'm currently making my way through the 2000+ pages of the EFI
specs so I probably got some things wrong above ...
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'
From: Chris Wilson @ 2016-11-09 14:12 UTC (permalink / raw)
To: kbuild test robot; +Cc: Daniel Vetter, intel-gfx, kbuild-all, dri-devel
In-Reply-To: <201611092234.E26yFYQw%fengguang.wu@intel.com>
On Wed, Nov 09, 2016 at 10:01:37PM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
> head: 77d150b90d58ae6a43bf67af28feb26384d06cd6
> commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict stackdepot usage to builtin drm.ko
> config: m68k-allyesconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 4.9.0
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout cd456f8d06d2036e1e013136c3fbf5721d04f6d7
> # save the attached .config to linux build tree
> make.cross ARCH=m68k
>
> All errors (new ones prefixed by >>):
>
> kernel/built-in.o: In function `backtrace_regression_test':
> >> backtracetest.c:(.text+0x550d4): undefined reference to `save_stack_trace'
> mm/built-in.o: In function `set_track':
> slub.c:(.text+0x41414): undefined reference to `save_stack_trace'
> drivers/built-in.o: In function `save_stack.isra.7':
> >> drm_mm.c:(.text+0x16be82): undefined reference to `save_stack_trace'
Anyone got an idea for this one? m68k is missing save_stack_trace().
There's no arch CONFIG_HAS_SAVE_STACK_TRACE, it looks like an oversight
in arch/m68k.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: Designware MAC reset timeout after Linux reboot
From: Ian Abbott @ 2016-11-09 14:10 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
In-Reply-To: <d728234e-959a-c21d-7df1-b530355425de@mev.co.uk>
On 08/11/16 12:13, Ian Abbott wrote:
> On 08/11/16 08:08, Sascha Hauer wrote:
>> Hi Ian,
>>
>> On Mon, Nov 07, 2016 at 05:56:51PM +0000, Ian Abbott wrote:
>>> Perhaps the timeout isn't waiting long enough. If I interrupt the 'ifup
>>> eth0' command and display the approriate 'Bus_Mode' register
>>> (0xff703000)
>>> with the 'md' command, the DMAMAC_SRST bit (bit 0) is no longer set:
>>>
>>> barebox@xxxx:/ md -l 0xff703000+4
>>> ff703000: 00020100
>>
>> The timeout is 10ms, this should be way enough. The return value of
>> dwc_ether_init() is not checked, so the driver happily continues with
>> further register writes, I assume there must be something that clears
>> this bit afterwards, either directly or indirectly.
>
> The bit is supposed to clear itself, but I guess something else could be
> clearing it too.
>
> The code to reset the MAC DMA controller in Linux kernel 4.1 is
> dwmac1000_dma_init() in
> "drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c". In Linux kernel
> 4.6, the function is dwmac_dma_reset() in "dwmac_lib.c". In both cases,
> the code to reset the DMA controller is basically as follows:
>
> u32 value = readl(ioaddr + DMA_BUS_MODE);
> int limit;
>
> /* DMA SW reset */
> value |= DMA_BUS_MODE_SFT_RESET;
> writel(value, ioaddr + DMA_BUS_MODE);
> limit = 10;
> while (limit--) {
> if (!(readl(ioaddr + DMA_BUS_MODE) & DMA_BUS_MODE_SFT_RESET))
> break;
> mdelay(10);
> }
> if (limit < 0)
> return -EBUSY;
>
> It's interesting that it only bothers to check for reset completion
> every 10 ms (timing out after 100 ms), so it must be expecting it to
> take a while!
>
> I'll experiment with the timeout on my board to see if the bit ever
> clears itself.
>
The problem seems to be related to some other problems I've been having
with the Ethernet on this prototype board, which is something to do with
the PHY chip's passive support components (inductors, capacitors, etc.)
This problem manifests as lower-than-expected 'iperf' times when the
Ethernet port is plugged into certain models of Ethernet switch.
I experimented with the timeout in mac_reset() in designware.c, setting
it to 1 second, and printing out a debug message with the time taken for
the reset to complete.
After 20 trials of rebooting from Linux to barebox and issuing the 'ifup
eth0' command, I got a pretty random spread of times between 29.3 and
850.2 ms, with a mean of 312.5 ms. (It looks like a pretty linear
distribution. Some other stats: Q1: 141.4 ms, Median: 240.1 ms, Q3:
480.2 ms, SD: 211.9 ms.)
I ran another trial with the is_timeout() call replaced with
is_timeout_non_interruptible() and got a similar random spread of times
(but smaller than the first trial) from 11.4 ms to 654.6 ms, with a mean
of 266.2 ms.
Both of those trials were performed with the Ethernet port connected to
a 1000 Base-T Ethernet switch.
Now here's the kicker.... If I plug it into a different brand of 1000
Base-T Ethernet switch, the mac_reset() times (after rebooting from
Linux) are more like 360 ns (not ms!). If I plug it into a 100 Base-T
switch, the times are more more like 900 ns to 2300 ns. If I disconnect
it completely, the times are about 360 ns.
For comparison, after running 'ifup eth0' after powering up into
barebox, the mac_reset() times are about 360 ns independent of what the
Ethernet port is plugged into.
I'm still not sure what state my Linux kernel is leaving the Ethernet
controller and PHY in following a reboot, but I'm reasonably confident
the problem is related to the PHY hardware components on my board.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [Qemu-devel] [PULL 2/2] usbredir: free vm_change_state_handler in usbredir destroy dispatch
From: Gerd Hoffmann @ 2016-11-09 13:33 UTC (permalink / raw)
To: qemu-devel; +Cc: Li Qiang, Gerd Hoffmann
In-Reply-To: <1478698412-4865-1-git-send-email-kraxel@redhat.com>
From: Li Qiang <liqiang6-s@360.cn>
In usbredir destroy dispatch function, it doesn't free the vm change
state handler once registered in usbredir_realize function. This will
lead a memory leak issue. This patch avoid this.
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 58216976.d0236b0a.77b99.bcd6@mx.google.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
hw/usb/redirect.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 528081e..a657237 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -132,6 +132,7 @@ struct USBRedirDevice {
struct usbredirfilter_rule *filter_rules;
int filter_rules_count;
int compatible_speedmask;
+ VMChangeStateEntry *vmstate;
};
#define TYPE_USB_REDIR "usb-redir"
@@ -1411,7 +1412,8 @@ static void usbredir_realize(USBDevice *udev, Error **errp)
usbredir_chardev_read, usbredir_chardev_event,
dev, NULL, true);
- qemu_add_vm_change_state_handler(usbredir_vm_state_change, dev);
+ dev->vmstate =
+ qemu_add_vm_change_state_handler(usbredir_vm_state_change, dev);
}
static void usbredir_cleanup_device_queues(USBRedirDevice *dev)
@@ -1450,6 +1452,7 @@ static void usbredir_handle_destroy(USBDevice *udev)
}
free(dev->filter_rules);
+ qemu_del_vm_change_state_handler(dev->vmstate);
}
static int usbredir_check_filter(USBRedirDevice *dev)
--
1.8.3.1
^ permalink raw reply related
* [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
From: ayaka @ 2016-11-09 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16dfbe16-eae7-8da9-4108-07e623210d35@rock-chips.com>
On 10/28/2016 05:29 PM, Randy Li wrote:
>
>
> On 10/28/2016 05:11 PM, Shawn Lin wrote:
>> On 2016/10/23 3:18, Randy Li wrote:
>>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>>> This patch would try to enable them first. The eDP_AVDD_1V8 more
>>> likely to be applied to eDP phy, but I have no time to confirmed
>>> it yet.
>>
>> Comfirm it or at least someone should be able to answer your
>> question, Mark?
> I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a
short time.
>>
>> Have you considered to add some details about vcc-supply and vccio-
>> supply for your analogix_dp-rockchip.txt ?
>>
>> From your commit msg, these two properties are more likely to be
>> required but the code itself tell me them should be optional(from the
>> point of backward compatibility, it should also be optinoal).
> Yes, I keep it optional for the same reason. Most of boards won't turn
> off those power supply and may use some fixed regulators.
>>
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> ---
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
>>> +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 8548e82..6bf0441 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/of_device.h>
>>> #include <linux/of_graph.h>
>>> #include <linux/regmap.h>
>>> +#include <linux/regulator/consumer.h>
>>> #include <linux/reset.h>
>>> #include <linux/clk.h>
>>>
>>> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>>> struct clk *grfclk;
>>> struct regmap *grf;
>>> struct reset_control *rst;
>>> + struct regulator_bulk_data supplies[2];
>>>
>>> struct work_struct psr_work;
>>> spinlock_t psr_lock;
>>> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> cancel_work_sync(&dp->psr_work);
>>>
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret) {
>>> + dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> clk_disable_unprepare(dp->pclk);
>>>
>>> + regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
>>> rockchip_dp_device *dp)
>>> return PTR_ERR(dp->rst);
>>> }
>>>
>>> + dp->supplies[0].supply = "vcc";
>>> + dp->supplies[1].supply = "vccio";
>>> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to get regulators: %d\n", ret);
>>> + }
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
From: ayaka @ 2016-11-09 14:10 UTC (permalink / raw)
To: Randy Li, Shawn Lin, dri-devel
Cc: heiko, airlied, linux-kernel, linux-rockchip, linux-arm-kernel,
mark.yao
In-Reply-To: <16dfbe16-eae7-8da9-4108-07e623210d35@rock-chips.com>
On 10/28/2016 05:29 PM, Randy Li wrote:
>
>
> On 10/28/2016 05:11 PM, Shawn Lin wrote:
>> On 2016/10/23 3:18, Randy Li wrote:
>>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>>> This patch would try to enable them first. The eDP_AVDD_1V8 more
>>> likely to be applied to eDP phy, but I have no time to confirmed
>>> it yet.
>>
>> Comfirm it or at least someone should be able to answer your
>> question, Mark?
> I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a
short time.
>>
>> Have you considered to add some details about vcc-supply and vccio-
>> supply for your analogix_dp-rockchip.txt ?
>>
>> From your commit msg, these two properties are more likely to be
>> required but the code itself tell me them should be optional(from the
>> point of backward compatibility, it should also be optinoal).
> Yes, I keep it optional for the same reason. Most of boards won't turn
> off those power supply and may use some fixed regulators.
>>
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> ---
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
>>> +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 8548e82..6bf0441 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/of_device.h>
>>> #include <linux/of_graph.h>
>>> #include <linux/regmap.h>
>>> +#include <linux/regulator/consumer.h>
>>> #include <linux/reset.h>
>>> #include <linux/clk.h>
>>>
>>> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>>> struct clk *grfclk;
>>> struct regmap *grf;
>>> struct reset_control *rst;
>>> + struct regulator_bulk_data supplies[2];
>>>
>>> struct work_struct psr_work;
>>> spinlock_t psr_lock;
>>> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> cancel_work_sync(&dp->psr_work);
>>>
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret) {
>>> + dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> clk_disable_unprepare(dp->pclk);
>>>
>>> + regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
>>> rockchip_dp_device *dp)
>>> return PTR_ERR(dp->rst);
>>> }
>>>
>>> + dp->supplies[0].supply = "vcc";
>>> + dp->supplies[1].supply = "vccio";
>>> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to get regulators: %d\n", ret);
>>> + }
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>>
>>
>>
>
^ permalink raw reply
* [PATCH 1/5] iommu: Allow taking a reference on a group directly
From: Sricharan @ 2016-11-09 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy@arm.com>
Hi,
>-----Original Message-----
>From: Robin Murphy [mailto:robin.murphy at arm.com]
>Sent: Wednesday, November 09, 2016 6:17 PM
>To: joro at 8bytes.org
>Cc: will.deacon at arm.com; sricharan at codeaurora.org; iommu at lists.linux-foundation.org; linux-arm-kernel at lists.infradead.org
>Subject: [PATCH 1/5] iommu: Allow taking a reference on a group directly
>
>iommu_group_get_for_dev() expects that the IOMMU driver's device_group
>callback return a group with a reference held for the given device.
>Whilst allocating a new group is fine, and pci_device_group() correctly
>handles reusing an existing group, there is no general means for IOMMU
>drivers doing their own group lookup to take additional references on an
>existing group pointer without having to also store device pointers or
>resort to elaborate trickery.
>
>Add an IOMMU-driver-specific function to fill the hole.
>
>Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>---
> drivers/iommu/iommu.c | 14 ++++++++++++++
> include/linux/iommu.h | 1 +
> 2 files changed, 15 insertions(+)
>
>diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>index 9a2f1960873b..b0b052bc6bb5 100644
>--- a/drivers/iommu/iommu.c
>+++ b/drivers/iommu/iommu.c
>@@ -552,6 +552,20 @@ struct iommu_group *iommu_group_get(struct device *dev)
> EXPORT_SYMBOL_GPL(iommu_group_get);
>
> /**
>+ * __iommu_group_get - Increment reference on a group
>+ * @group: the group to use, must not be NULL
>+ *
>+ * This function may be called by internal iommu driver group management
>+ * when the context of a struct device pointer is not available. It is
>+ * not for general use. Returns the given group for convenience.
>+ */
>+struct iommu_group *__iommu_group_get(struct iommu_group *group)
>+{
>+ kobject_get(group->devices_kobj);
>+ return group;
>+}
>+
>+/**
Acked-by: sricharan at codeaurora.org
Regards,
Sricharan
^ permalink raw reply
* RE: [PATCH 1/5] iommu: Allow taking a reference on a group directly
From: Sricharan @ 2016-11-09 14:10 UTC (permalink / raw)
To: 'Robin Murphy', joro-zLv9SwRftAIdnm+yROfE0A
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <3922e1f14d8ecb50440b2d9b0d1123f3c9307fc5.1478695557.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
Hi,
>-----Original Message-----
>From: Robin Murphy [mailto:robin.murphy-5wv7dgnIgG8@public.gmane.org]
>Sent: Wednesday, November 09, 2016 6:17 PM
>To: joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org
>Cc: will.deacon-5wv7dgnIgG8@public.gmane.org; sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>Subject: [PATCH 1/5] iommu: Allow taking a reference on a group directly
>
>iommu_group_get_for_dev() expects that the IOMMU driver's device_group
>callback return a group with a reference held for the given device.
>Whilst allocating a new group is fine, and pci_device_group() correctly
>handles reusing an existing group, there is no general means for IOMMU
>drivers doing their own group lookup to take additional references on an
>existing group pointer without having to also store device pointers or
>resort to elaborate trickery.
>
>Add an IOMMU-driver-specific function to fill the hole.
>
>Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>---
> drivers/iommu/iommu.c | 14 ++++++++++++++
> include/linux/iommu.h | 1 +
> 2 files changed, 15 insertions(+)
>
>diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>index 9a2f1960873b..b0b052bc6bb5 100644
>--- a/drivers/iommu/iommu.c
>+++ b/drivers/iommu/iommu.c
>@@ -552,6 +552,20 @@ struct iommu_group *iommu_group_get(struct device *dev)
> EXPORT_SYMBOL_GPL(iommu_group_get);
>
> /**
>+ * __iommu_group_get - Increment reference on a group
>+ * @group: the group to use, must not be NULL
>+ *
>+ * This function may be called by internal iommu driver group management
>+ * when the context of a struct device pointer is not available. It is
>+ * not for general use. Returns the given group for convenience.
>+ */
>+struct iommu_group *__iommu_group_get(struct iommu_group *group)
>+{
>+ kobject_get(group->devices_kobj);
>+ return group;
>+}
>+
>+/**
Acked-by: sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
Regards,
Sricharan
^ permalink raw reply
* [PATCH] usb: musb: omap2430: make complain on -EPROBE_DEFER dev_dbg
From: Ladislav Michl @ 2016-11-09 14:10 UTC (permalink / raw)
To: Bin Liu, Tony Lindgren
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
There is no point having this complaint to be dev_err as it is just adding
noise to bootlog.
Signed-off-by: Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
---
drivers/usb/musb/omap2430.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 451b372..7c9aa5e 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -277,7 +277,7 @@ static int omap2430_musb_init(struct musb *musb)
if (status == -ENXIO)
return status;
- dev_err(dev, "HS USB OTG: no transceiver configured\n");
+ dev_dbg(dev, "HS USB OTG: no transceiver configured\n");
return -EPROBE_DEFER;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [U-Boot] [PATCH RESEND 0/9] sunxi: chip: Enable the DIP auto-detection
From: Maxime Ripard @ 2016-11-09 14:10 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161109034418.GL6637@bill-the-cat>
Hi Tom,
On Tue, Nov 08, 2016 at 10:44:18PM -0500, Tom Rini wrote:
> On Tue, Nov 08, 2016 at 11:19:20AM +0100, Maxime Ripard wrote:
>
> [snip]
> > I think the biggest drawback at the moment is that we maintain a list of
> > DIPs and the actions needed directly into the C code, which will make it
> > quite hard to customise for end users and tedious to maintain in the long
> > term. I couldn't really get my head around a better solution, so feel free
> > to suggest alternative approaches.
>
> A thought I had after reading over 8/9 in the series was, could we try
> something like:
> - In C, loop over everything in w1 and set environment variables based
> on each thing we find.
> - In a CONFIG_PREBOOT load a U-Boot shell script in that will look for
> the right env variables to be set for a given DIP and then do whatever
> is needed to load in the overlay.
>
> Does that make sense?
I thought about an environment-based solution too, but I was pretty
worried about its scalability. But I guesse that's also the easiest
thing to modify by end-users.
However, we have basically, three things to do (so far)
1) Modify the U-Boot environment before the display is initialized
2) Modify the kernel command line
3) Apply an overlay
I think CONFIG_PREBOOT is too late for 1, because the display is
already initialized, and too early for 2 and 3, because the command
line and DT will probably be set / loaded at bootcmd time.
I think we can decouple 1 and 2 from 3, since doing 2 too early is not
an issue, because we might have boards that require to load some
overlay but wouldn't need to make environment modifications (like an
MMC DIP), or the other way around (even though I fail to see a use
case for that at the moment).
So we're left with basically two things:
- Do a bunch of modifications in the environment early
- And apply the overlay very late (basically right before booting
the kernel)
So we could do something like having an environment script called
dip-<vid>-<pid>-setup called when a DIP is detected (if it exists),
and keep the DT overlay logic in its current form.
What do you think?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161109/11bba8a8/attachment.sig>
^ permalink raw reply
* [U-Boot] [PATCH v2 2/4] serial: pxa: integrate optional driver model handling
From: Marek Vasut @ 2016-11-09 14:10 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1478597691-10816-3-git-send-email-marcel.ziswiler@toradex.com>
On 11/08/2016 10:34 AM, Marcel Ziswiler wrote:
> Optional driver model handling integration.
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
>
> Changes in v2: None
[...]
> @@ -164,6 +130,7 @@ void pxa_putc_dev(unsigned int uart_index, const char c)
> if (!uart_regs)
> hang();
>
> +
Remove this one.
> while (!(readl(&uart_regs->lsr) & LSR_TEMT))
> WATCHDOG_RESET();
> writel(c, &uart_regs->thr);
> @@ -297,3 +264,80 @@ void pxa_serial_initialize(void)
> serial_register(&serial_stuart_device);
> #endif
> }
Otherwise:
Reviewed-by: Marek Vasut <marex@denx.de>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 1/2] i2c: octeon: Fix register access
From: Paul Burton @ 2016-11-09 14:09 UTC (permalink / raw)
To: Jan Glauber; +Cc: linux-i2c, linux-mips, David Daney, Wolfram Sang, stable
In-Reply-To: <20161108071337.GA4601@hardcore>
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
On Tuesday, 8 November 2016 08:13:37 GMT Jan Glauber wrote:
> On Mon, Nov 07, 2016 at 08:09:20PM +0000, Paul Burton wrote:
> > Commit 70121f7f3725 ("i2c: octeon: thunderx: Limit register access
> > retries") attempted to replace potentially infinite loops with ones
> > which will time out using readq_poll_timeout, but in doing so it
> > inverted the condition for exiting this loop.
> >
> > Tested on a Rhino Labs UTM-8 with Octeon CN7130.
> >
> > Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> > Cc: Jan Glauber <jglauber@cavium.com>
> > Cc: David Daney <david.daney@cavium.com>
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > Cc: linux-i2c@vger.kernel.org
> >
> > ---
>
> Acked-by: Jan Glauber <jglauber@cavium.com>
>
> Thanks for spotting this. I think this should go into stable too for
> 4.8, so adding Cc: stable@vger.kernel.org.
Hi Jan,
...but the bad patch was only merged for v4.9-rc1?
Thanks,
Paul
>
> > drivers/i2c/busses/i2c-octeon-core.h | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-octeon-core.h
> > b/drivers/i2c/busses/i2c-octeon-core.h index 1db7c83..d980406 100644
> > --- a/drivers/i2c/busses/i2c-octeon-core.h
> > +++ b/drivers/i2c/busses/i2c-octeon-core.h
> > @@ -146,8 +146,9 @@ static inline void octeon_i2c_reg_write(struct
> > octeon_i2c *i2c, u64 eop_reg, u8>
> > __raw_writeq(SW_TWSI_V | eop_reg | data, i2c->twsi_base +
SW_TWSI(i2c));
> >
> > - readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp, tmp &
SW_TWSI_V,
> > - I2C_OCTEON_EVENT_WAIT, i2c->adap.timeout);
> > + readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > + i2c->adap.timeout);
> >
> > }
> >
> > #define octeon_i2c_ctl_write(i2c, val) \
> >
> > @@ -173,7 +174,7 @@ static inline int octeon_i2c_reg_read(struct
> > octeon_i2c *i2c, u64 eop_reg,>
> > __raw_writeq(SW_TWSI_V | eop_reg | SW_TWSI_R, i2c->twsi_base +
> > SW_TWSI(i2c));
> >
> > ret = readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> >
> > - tmp & SW_TWSI_V, I2C_OCTEON_EVENT_WAIT,
> > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> >
> > i2c->adap.timeout);
> >
> > if (error)
> >
> > *error = ret;
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] i2c: octeon: Fix register access
From: Paul Burton @ 2016-11-09 14:09 UTC (permalink / raw)
To: Jan Glauber; +Cc: linux-i2c, linux-mips, David Daney, Wolfram Sang, stable
In-Reply-To: <20161108071337.GA4601@hardcore>
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
On Tuesday, 8 November 2016 08:13:37 GMT Jan Glauber wrote:
> On Mon, Nov 07, 2016 at 08:09:20PM +0000, Paul Burton wrote:
> > Commit 70121f7f3725 ("i2c: octeon: thunderx: Limit register access
> > retries") attempted to replace potentially infinite loops with ones
> > which will time out using readq_poll_timeout, but in doing so it
> > inverted the condition for exiting this loop.
> >
> > Tested on a Rhino Labs UTM-8 with Octeon CN7130.
> >
> > Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> > Cc: Jan Glauber <jglauber@cavium.com>
> > Cc: David Daney <david.daney@cavium.com>
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > Cc: linux-i2c@vger.kernel.org
> >
> > ---
>
> Acked-by: Jan Glauber <jglauber@cavium.com>
>
> Thanks for spotting this. I think this should go into stable too for
> 4.8, so adding Cc: stable@vger.kernel.org.
Hi Jan,
...but the bad patch was only merged for v4.9-rc1?
Thanks,
Paul
>
> > drivers/i2c/busses/i2c-octeon-core.h | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-octeon-core.h
> > b/drivers/i2c/busses/i2c-octeon-core.h index 1db7c83..d980406 100644
> > --- a/drivers/i2c/busses/i2c-octeon-core.h
> > +++ b/drivers/i2c/busses/i2c-octeon-core.h
> > @@ -146,8 +146,9 @@ static inline void octeon_i2c_reg_write(struct
> > octeon_i2c *i2c, u64 eop_reg, u8>
> > __raw_writeq(SW_TWSI_V | eop_reg | data, i2c->twsi_base +
SW_TWSI(i2c));
> >
> > - readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp, tmp &
SW_TWSI_V,
> > - I2C_OCTEON_EVENT_WAIT, i2c->adap.timeout);
> > + readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > + i2c->adap.timeout);
> >
> > }
> >
> > #define octeon_i2c_ctl_write(i2c, val) \
> >
> > @@ -173,7 +174,7 @@ static inline int octeon_i2c_reg_read(struct
> > octeon_i2c *i2c, u64 eop_reg,>
> > __raw_writeq(SW_TWSI_V | eop_reg | SW_TWSI_R, i2c->twsi_base +
> > SW_TWSI(i2c));
> >
> > ret = readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> >
> > - tmp & SW_TWSI_V, I2C_OCTEON_EVENT_WAIT,
> > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> >
> > i2c->adap.timeout);
> >
> > if (error)
> >
> > *error = ret;
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] usb: musb: omap2430: use dev_err
From: Ladislav Michl @ 2016-11-09 14:09 UTC (permalink / raw)
To: Bin Liu, Tony Lindgren
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Replace pr_err with dev_err to print also device name.
Signed-off-by: Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
---
drivers/usb/musb/omap2430.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index cc12254..451b372 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -277,12 +277,12 @@ static int omap2430_musb_init(struct musb *musb)
if (status == -ENXIO)
return status;
- pr_err("HS USB OTG: no transceiver configured\n");
+ dev_err(dev, "HS USB OTG: no transceiver configured\n");
return -EPROBE_DEFER;
}
if (IS_ERR(musb->phy)) {
- pr_err("HS USB OTG: no PHY configured\n");
+ dev_err(dev, "HS USB OTG: no PHY configured\n");
return PTR_ERR(musb->phy);
}
musb->isr = omap2430_musb_interrupt;
@@ -301,7 +301,7 @@ static int omap2430_musb_init(struct musb *musb)
musb_writel(musb->mregs, OTG_INTERFSEL, l);
- pr_debug("HS USB OTG: revision 0x%x, sysconfig 0x%02x, "
+ dev_dbg(dev, "HS USB OTG: revision 0x%x, sysconfig 0x%02x, "
"sysstatus 0x%x, intrfsel 0x%x, simenable 0x%x\n",
musb_readl(musb->mregs, OTG_REVISION),
musb_readl(musb->mregs, OTG_SYSCONFIG),
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [U-Boot] [PATCH v2 1/4] serial: pxa: use kconfig for serial configuration
From: Marek Vasut @ 2016-11-09 14:09 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1478597691-10816-2-git-send-email-marcel.ziswiler@toradex.com>
On 11/08/2016 10:34 AM, Marcel Ziswiler wrote:
> Migrate the PXA serial driver to be configured via Kconfig.
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
>
> Changes in v2: None
Reviewed-by: Marek Vasut <marex@denx.de>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [libvirt test] 102058: tolerable all pass - PUSHED
From: osstest service owner @ 2016-11-09 14:09 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 9224 bytes --]
flight 102058 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102058/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 102026
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 102026
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 102026
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 102026
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
version targeted for testing:
libvirt f694f3ff6bd8a94d71582adab669b0dcd1f7bfe5
baseline version:
libvirt 214c226f9e1440f02ba338b485899b62d9e6bdf8
Last test of basis 102026 2016-11-08 04:28:21 Z 1 days
Testing same since 102058 2016-11-09 04:33:12 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Daniel P. Berrange <berrange@redhat.com>
Dawid Zamirski <dzamirski@datto.com>
Félix Bouliane <felixbouliane@gmail.com>
John Ferlan <jferlan@redhat.com>
Michal Privoznik <mprivozn@redhat.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-amd64-libvirt-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=f694f3ff6bd8a94d71582adab669b0dcd1f7bfe5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt f694f3ff6bd8a94d71582adab669b0dcd1f7bfe5
+ branch=libvirt
+ revision=f694f3ff6bd8a94d71582adab669b0dcd1f7bfe5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xf694f3ff6bd8a94d71582adab669b0dcd1f7bfe5 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : daily-cron.libvirt
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.libvirt
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree libvirt
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/libvirt
+ git push osstest@xenbits.xen.org:/home/xen/git/libvirt.git f694f3ff6bd8a94d71582adab669b0dcd1f7bfe5:refs/heads/xen-tested-master
To osstest@xenbits.xen.org:/home/xen/git/libvirt.git
214c226..f694f3f f694f3ff6bd8a94d71582adab669b0dcd1f7bfe5 -> xen-tested-master
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
From: ayaka @ 2016-11-09 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16dfbe16-eae7-8da9-4108-07e623210d35@rock-chips.com>
On 10/28/2016 05:29 PM, Randy Li wrote:
>
>
> On 10/28/2016 05:11 PM, Shawn Lin wrote:
>> On 2016/10/23 3:18, Randy Li wrote:
>>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>>> This patch would try to enable them first. The eDP_AVDD_1V8 more
>>> likely to be applied to eDP phy, but I have no time to confirmed
>>> it yet.
>>
>> Comfirm it or at least someone should be able to answer your
>> question, Mark?
> I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a
short time.
>>
>> Have you considered to add some details about vcc-supply and vccio-
>> supply for your analogix_dp-rockchip.txt ?
>>
>> From your commit msg, these two properties are more likely to be
>> required but the code itself tell me them should be optional(from the
>> point of backward compatibility, it should also be optinoal).
> Yes, I keep it optional for the same reason. Most of boards won't turn
> off those power supply and may use some fixed regulators.
>>
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> ---
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
>>> +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 8548e82..6bf0441 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/of_device.h>
>>> #include <linux/of_graph.h>
>>> #include <linux/regmap.h>
>>> +#include <linux/regulator/consumer.h>
>>> #include <linux/reset.h>
>>> #include <linux/clk.h>
>>>
>>> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>>> struct clk *grfclk;
>>> struct regmap *grf;
>>> struct reset_control *rst;
>>> + struct regulator_bulk_data supplies[2];
>>>
>>> struct work_struct psr_work;
>>> spinlock_t psr_lock;
>>> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> cancel_work_sync(&dp->psr_work);
>>>
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret) {
>>> + dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> clk_disable_unprepare(dp->pclk);
>>>
>>> + regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
>>> rockchip_dp_device *dp)
>>> return PTR_ERR(dp->rst);
>>> }
>>>
>>> + dp->supplies[0].supply = "vcc";
>>> + dp->supplies[1].supply = "vccio";
>>> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to get regulators: %d\n", ret);
>>> + }
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP
From: ayaka @ 2016-11-09 14:08 UTC (permalink / raw)
To: Randy Li, Shawn Lin, dri-devel
Cc: heiko, airlied, linux-kernel, linux-rockchip, linux-arm-kernel,
mark.yao
In-Reply-To: <16dfbe16-eae7-8da9-4108-07e623210d35@rock-chips.com>
On 10/28/2016 05:29 PM, Randy Li wrote:
>
>
> On 10/28/2016 05:11 PM, Shawn Lin wrote:
>> On 2016/10/23 3:18, Randy Li wrote:
>>> I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
>>> RK3288, once trying to enable the pclk clock, the kernel would dead.
>>> This patch would try to enable them first. The eDP_AVDD_1V8 more
>>> likely to be applied to eDP phy, but I have no time to confirmed
>>> it yet.
>>
>> Comfirm it or at least someone should be able to answer your
>> question, Mark?
> I just forget to ask the IC department, the TRM didn't cover that.
The IC staff have told me that the AVDD_1V8 is for phy, but AVDD_1V0 is
for both of them. I should find a way to make the power sequence correctly.
I am a little busy recently, a new patch would not be available in a
short time.
>>
>> Have you considered to add some details about vcc-supply and vccio-
>> supply for your analogix_dp-rockchip.txt ?
>>
>> From your commit msg, these two properties are more likely to be
>> required but the code itself tell me them should be optional(from the
>> point of backward compatibility, it should also be optinoal).
> Yes, I keep it optional for the same reason. Most of boards won't turn
> off those power supply and may use some fixed regulators.
>>
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> ---
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25
>>> +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index 8548e82..6bf0441 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -17,6 +17,7 @@
>>> #include <linux/of_device.h>
>>> #include <linux/of_graph.h>
>>> #include <linux/regmap.h>
>>> +#include <linux/regulator/consumer.h>
>>> #include <linux/reset.h>
>>> #include <linux/clk.h>
>>>
>>> @@ -70,6 +71,7 @@ struct rockchip_dp_device {
>>> struct clk *grfclk;
>>> struct regmap *grf;
>>> struct reset_control *rst;
>>> + struct regulator_bulk_data supplies[2];
>>>
>>> struct work_struct psr_work;
>>> spinlock_t psr_lock;
>>> @@ -146,6 +148,13 @@ static int rockchip_dp_poweron(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> cancel_work_sync(&dp->psr_work);
>>>
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret) {
>>> + dev_err(dp->dev, "failed to enable vdd supply %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>> @@ -168,6 +177,9 @@ static int rockchip_dp_powerdown(struct
>>> analogix_dp_plat_data *plat_data)
>>>
>>> clk_disable_unprepare(dp->pclk);
>>>
>>> + regulator_bulk_disable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -323,6 +335,19 @@ static int rockchip_dp_init(struct
>>> rockchip_dp_device *dp)
>>> return PTR_ERR(dp->rst);
>>> }
>>>
>>> + dp->supplies[0].supply = "vcc";
>>> + dp->supplies[1].supply = "vccio";
>>> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to get regulators: %d\n", ret);
>>> + }
>>> + ret = regulator_bulk_enable(ARRAY_SIZE(dp->supplies),
>>> + dp->supplies);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable regulators: %d\n", ret);
>>> + }
>>> +
>>> ret = clk_prepare_enable(dp->pclk);
>>> if (ret < 0) {
>>> dev_err(dp->dev, "failed to enable pclk %d\n", ret);
>>>
>>
>>
>
^ permalink raw reply
* Re: bluestore SMR update?
From: Sage Weil @ 2016-11-09 14:08 UTC (permalink / raw)
To: Darrell Enns; +Cc: 'ceph-devel@vger.kernel.org'
In-Reply-To: <04EA9170BFDB1B4BB5C8DF4AA2815C11BE932B8F@KNEX2.knc.local>
On Wed, 9 Nov 2016, Darrell Enns wrote:
> Is there any update on the GSOC Bluestore SMR project? It seems that the
> progress report wiki page has not been updated since May. I'm very
> interested in the findings and what (if anything) has yet to be done to
> improve bluestore SMR support.
We didn't complete the project, and work here as stalled while we focus on
higher priority issues. If you're interested in picking the work back
up, we'd love to talk about it!
sage
^ permalink raw reply
* Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
From: Paul Burton @ 2016-11-09 14:07 UTC (permalink / raw)
To: Jan Glauber; +Cc: linux-i2c, linux-mips, David Daney, Peter Swain, Wolfram Sang
In-Reply-To: <20161109134103.GC2960@hardcore>
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
On Wednesday, 9 November 2016 14:41:03 GMT Jan Glauber wrote:
> Hi Paul,
>
> I think we should revert commit "70121f7 i2c: octeon: thunderx: Limit
> register access retries". With debugging enabled I'm getting:
>
> <snip>
>
> This is not caused by the usleep inside the wait_event but by
> readq_poll_timeout(). Could you try if it works for you if you only revert
> this patch?
>
> Thanks,
> Jan
Hi Jan,
If I drop both my patches & just revert 70121f7f3725 ("i2c: octeon: thunderx:
Limit register access retries") sadly it doesn't fix my system. A boot of a
cavium_octeon_defconfig kernel with initcall_debug ends with:
calling octeon_mgmt_mod_init+0x0/0x28 @ 1
initcall octeon_mgmt_mod_init+0x0/0x28 returned 0 after 67 usecs
calling ds1307_driver_init+0x0/0x10 @ 1
initcall ds1307_driver_init+0x0/0x10 returned 0 after 19 usecs
calling octeon_i2c_driver_init+0x0/0x10 @ 1
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata1.00: ATA-9: SanDisk SDSSDA240G, Z22000RL, max UDMA/133
ata1.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA SanDisk SDSSDA24 00RL PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
ata2: SATA link down (SStatus 0 SControl 300)
random: crng init done
As you can see octeon_i2c_driver_init never returns. Are you able to test on
one of your MIPS-based systems?
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
From: Paul Burton @ 2016-11-09 14:07 UTC (permalink / raw)
To: Jan Glauber; +Cc: linux-i2c, linux-mips, David Daney, Peter Swain, Wolfram Sang
In-Reply-To: <20161109134103.GC2960@hardcore>
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
On Wednesday, 9 November 2016 14:41:03 GMT Jan Glauber wrote:
> Hi Paul,
>
> I think we should revert commit "70121f7 i2c: octeon: thunderx: Limit
> register access retries". With debugging enabled I'm getting:
>
> <snip>
>
> This is not caused by the usleep inside the wait_event but by
> readq_poll_timeout(). Could you try if it works for you if you only revert
> this patch?
>
> Thanks,
> Jan
Hi Jan,
If I drop both my patches & just revert 70121f7f3725 ("i2c: octeon: thunderx:
Limit register access retries") sadly it doesn't fix my system. A boot of a
cavium_octeon_defconfig kernel with initcall_debug ends with:
calling octeon_mgmt_mod_init+0x0/0x28 @ 1
initcall octeon_mgmt_mod_init+0x0/0x28 returned 0 after 67 usecs
calling ds1307_driver_init+0x0/0x10 @ 1
initcall ds1307_driver_init+0x0/0x10 returned 0 after 19 usecs
calling octeon_i2c_driver_init+0x0/0x10 @ 1
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata1.00: ATA-9: SanDisk SDSSDA240G, Z22000RL, max UDMA/133
ata1.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA SanDisk SDSSDA24 00RL PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
ata2: SATA link down (SStatus 0 SControl 300)
random: crng init done
As you can see octeon_i2c_driver_init never returns. Are you able to test on
one of your MIPS-based systems?
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] usb: musb: don't complain on -EPROBE_DEFER when initializing controller
From: Ladislav Michl @ 2016-11-09 14:08 UTC (permalink / raw)
To: Bin Liu, Tony Lindgren
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Don't complain on -EPROBE_DEFER when initializing controller,
the driver probe will be retried later.
Signed-off-by: Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
---
drivers/usb/musb/musb_core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 27dadc0..77fd97b 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2329,8 +2329,9 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
musb_platform_exit(musb);
fail1:
- dev_err(musb->controller,
- "musb_init_controller failed with status %d\n", status);
+ if (status != -EPROBE_DEFER)
+ dev_err(musb->controller,
+ "%s failed with status %d\n", __func__, status);
musb_free(musb);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: How to handle meta-intel/openembedded repos with multiple developers
From: Mike Looijmans @ 2016-11-09 14:07 UTC (permalink / raw)
To: yocto
In-Reply-To: <CAEjjReLCNOKCq5dawyvbFyH=M5B1eot36SLuwCXMFJ1r_o-fUg@mail.gmail.com>
Git submodules work fine for this.
In general, for each project I create a top-level repo that has the OE repos
as submodule. The project repo also contains the project-specific recipes.
On 07-11-16 20:31, Chris Z. wrote:
> Hi,
>
> How you store your project configuration ? How you prepare workspace (download
> each layer separately)?
> Basic stuff, SW release should be reproducible (in easy way). Store somewhere
> used hash of each piece or use tags. Non company assets should be already
> somehow tagged or you use HEAD or master/-next ?
>
> Br,
> Chris Z
>
> On Thu, Oct 27, 2016 at 8:22 AM, Edward Wingate <edwingate8@gmail.com
> <mailto:edwingate8@gmail.com>> wrote:
>
> On Thu, Mar 3, 2016 at 8:27 AM, Mark Hatle <mark.hatle@windriver.com
> <mailto:mark.hatle@windriver.com>> wrote:
> > At some point during product development a lead/architect needs to make the
> > decision to 'freeze' development and at that point everything is
> tagged/branched
> > and only backports are used from them on. (If the number of backports
> gets too
> > large, you MIGHT decide to selectively rebase.)
>
> I'm currently trying to figure out with how to control external layers
> in my Yocto build and found this thread. I'm a little unclear on how
> to track a release to the version used on non-company layers. Say I'm
> using poky, meta-openembedded, meta-xilinx and then my own layer,
> meta-me. When I freeze development and do a release, I can tag
> meta-me, but because I also treat non-company assets as RO, I
> shouldn't tag poky, meta-openembedded nor meta-xilinx (or should I? Is
> this where I use git's lightweight tagging as opposed to annotated
> tags?) When "everything is tagged/branched", does that somehow include
> tagging the non-company assets? Thanks for any help.
>
> Ed
> --
>
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
_______________________________________________
> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
> <https://lists.yoctoproject.org/listinfo/yocto>
>
>
>
>
^ permalink raw reply
* Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group
From: Xiao Guangrong @ 2016-11-09 14:00 UTC (permalink / raw)
To: Paolo Bonzini, Jike Song
Cc: Alex Williamson, kwankhede, cjia, kevin.tian, kvm
In-Reply-To: <02c27131-80fd-b882-1838-fe56f3f871d3@redhat.com>
On 11/09/2016 09:31 PM, Paolo Bonzini wrote:
>
>
> On 09/11/2016 14:06, Xiao Guangrong wrote:
>>
>>
>> On 11/09/2016 08:49 PM, Jike Song wrote:
>>
>>> +void vfio_group_attach_kvm(struct vfio_group *group, struct kvm *kvm,
>>> + void (*fn)(struct kvm *))
>>> +{
>>> + mutex_lock(&group->udata.lock);
>>
>> This lock is needed, please see below.
>
> *not* needed I guess.
Yes, indeed. Sorry for the typo. :(
>
>>> +
>>> + fn(kvm);
>>> + blocking_notifier_call_chain(&group->udata.notifier,
>>> + VFIO_GROUP_NOTIFY_ATTACH_KVM, kvm);
>>
>> As this is a callback before KVM releases its last refcount, i do not
>> think vendor driver need to get additional KVM refcount.
>
> The *group* driver doesn't need it indeed. The mdev vendor driver
> however does, so it will use kvm_get_kvm under its own mutex. That is:
Yes, own mutex is definitely can work.:) It is vendor driver internal
operation and it depends on the internal implementation.
My idea is that we can make sure the KVM instance is valid before calling
DETACH callback. So if we can properly release all the resource associated
with the kvm instance in this callback, it is okay without additional kvm
ref.
^ permalink raw reply
* Re: [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio
From: Mark Brown @ 2016-11-09 13:19 UTC (permalink / raw)
To: Pierre-Louis Bossart; +Cc: Takashi Iwai, intel-gfx, Rakesh A Ughreja
In-Reply-To: <d51d25f1-8bb2-961b-9677-8335ad4a4a29@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]
On Sun, Nov 06, 2016 at 11:42:31PM -0700, Pierre-Louis Bossart wrote:
> I am all for convergence when it makes sense but I don't see how
> hdmi-codec.h provides equivalent functionality for BYT/CHT with what was
> suggested in this patchset -derived from VED patches- and discussed earlier
> with intel-gfx folks, specifically how LPE pipe interrupts are
> masked/unmasked and passed to the audio driver? The BYT/CHT HDMI
Without knowing what these things are it's hard to comment but it does
seem that if Intel has a reasonable use case for them then so too will
other vendors at some point.
> functionality is also not modeled as an ASoC codec - which seems a
> dependency from the comments in hdmi-codec.h - since it's really part of the
> i915 hardware and exposed only as a set of registers+DMA, without any serial
> link interface typically needed for an external device or the internal
> HDAudio-display link.
None of which is at all unusal. The Intel hardware really doesn't seem
like the sort of special snowflake that people appear to believe it to
be.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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.